Tincr is a tool that arose from my own frustration with switching back and forth between Chrome Developer Tools to do debugging and my text editor to do coding. The idea behind Tincr is that you can save changes to your original source file from within Chrome Developer Tools. In addition, Tincr does auto-reloading of JavaScript and CSS changes made in other editors. It was partly inspired by two projects
I've used NPAPI to make the functionality self-contained in the extension. It doesn't require a proxy server or a separate application to interact with the file system. Even though it uses native code, it should work on OS X, Windows, and Linux.
I'm also trying to make it dead simple to configure for common web development platforms. To give you a complete illustration, let's say you're developing a Ruby on Rails web application. You would select "Ruby on Rails" in the dropdown on the Tincr panel and then select the local directory of your rails application. Once you've done that, Tincr knows enough about how a RoR application is structured that if you made a change inside of Chrome Developer Tools, it would be saved to the local file equivalent. If you made a change to an application script or stylesheet using TextMate or some other tool, the change would automatically be reloaded in Chrome without refreshing the whole page
It should "just work" for local files accessed at "file://" urls. It currently doesn't do pre-processing of things like CoffeeScript, SASS, LESS, etc. but I'm working on that right now.
I'm trying to get it released on the Chrome Web Store but since it contains an NPAPI plugin it's taking a while (it has been Pending Review for 11 days now).
> Tincr is a tool that arose from my own frustration with switching back and
> forth between Chrome Developer Tools to do debugging and my text editor to
> do coding. The idea behind Tincr is that you can save changes to your
> original source file from within Chrome Developer Tools. In addition, Tincr
> does auto-reloading of JavaScript and CSS changes made in other editors.
> I've used NPAPI to make the functionality self-contained in the extension.
> It doesn't require a proxy server or a separate application to interact with
> the file system. Even though it uses native code, it should work on OS X,
> Windows, and Linux.
> I'm also trying to make it dead simple to configure for common web
> development platforms. To give you a complete illustration, let's say you're
> developing a Ruby on Rails web application. You would select "Ruby on Rails"
> in the dropdown on the Tincr panel and then select the local directory of
> your rails application. Once you've done that, Tincr knows enough about how
> a RoR application is structured that if you made a change inside of Chrome
> Developer Tools, it would be saved to the local file equivalent. If you made
> a change to an application script or stylesheet using TextMate or some other
> tool, the change would automatically be reloaded in Chrome without
> refreshing the whole page
> It should "just work" for local files accessed at "file://" urls. It
> currently doesn't do pre-processing of things like CoffeeScript, SASS, LESS,
> etc. but I'm working on that right now.
> I'm trying to get it released on the Chrome Web Store but since it contains
> an NPAPI plugin it's taking a while (it has been Pending Review for 11 days
> now).
> Tincr is a tool that arose from my own frustration with switching back and forth between Chrome Developer Tools to do debugging and my text editor to do coding. The idea behind Tincr is that you can save changes to your original source file from within Chrome Developer Tools. In addition, Tincr does auto-reloading of JavaScript and CSS changes made in other editors.
> It was partly inspired by two projects > • Nikita Vasilyev's auto-save extension
> • http://livereload.com/ > I've used NPAPI to make the functionality self-contained in the extension. It doesn't require a proxy server or a separate application to interact with the file system. Even though it uses native code, it should work on OS X, Windows, and Linux.
> I'm also trying to make it dead simple to configure for common web development platforms. To give you a complete illustration, let's say you're developing a Ruby on Rails web application. You would select "Ruby on Rails" in the dropdown on the Tincr panel and then select the local directory of your rails application. Once you've done that, Tincr knows enough about how a RoR application is structured that if you made a change inside of Chrome Developer Tools, it would be saved to the local file equivalent. If you made a change to an application script or stylesheet using TextMate or some other tool, the change would automatically be reloaded in Chrome without refreshing the whole page
> It should "just work" for local files accessed at "file://" urls. It currently doesn't do pre-processing of things like CoffeeScript, SASS, LESS, etc. but I'm working on that right now.
> I'm trying to get it released on the Chrome Web Store but since it contains an NPAPI plugin it's taking a while (it has been Pending Review for 11 days now).
The toFile section specifies how it does saving from Chrome devtools. It iterates through the "from" regexes to match each resource url. If there is a match it converts it into a file using the "to" expression. It uses matching groups found with the "from" regex. The "to" path is relative to the base directory.
The fromFile section is for live reload. It's relative to the base directory. It's basically the toFile section in reverse. It's optional because tincr will infer the file-to-url relationships from the toFile section. In some cases, the inference isn't good enough. For example, with RoR, it's common to use SASS and coffeescript. Because they are converted to css and javascript, you can't do auto-save but you can do live reload. In my example above, the fromFile section is necessary because of this.
For something like Rails, it's not necessary since the Rails engine handles the conversion. It only applies to file:// urls.
My first iteration will only handle stuff that can be converted with pure javascript (i.e. LESS, Coffeescript). For things like SASS, I will need to write native code to shell out a ruby process unless I can find a better way.
On Tuesday, July 24, 2012 10:32:01 PM UTC+10, Nikita Vasilyev wrote:
> Thanks for the response, Ryan!
> On Jul 20, 2012, at 8:04 PM, ryanackley wrote: > > It currently doesn't do pre-processing of things like CoffeeScript, > SASS, LESS, etc. but I'm working on that right now.
> For something like Rails, it's not necessary since the Rails engine handles the conversion. It only applies to file:// urls.
> My first iteration will only handle stuff that can be converted with pure javascript (i.e. LESS, Coffeescript). For things like SASS, I will need to write native code to shell out a ruby process unless I can find a better way.
> On Tuesday, July 24, 2012 10:32:01 PM UTC+10, Nikita Vasilyev wrote:
> Thanks for the response, Ryan!
> On Jul 20, 2012, at 8:04 PM, ryanackley wrote: > > It currently doesn't do pre-processing of things like CoffeeScript, SASS, LESS, etc. but I'm working on that right now.
Yes, right now it's unfeasible but with sourcemaps it seems trivial for the devtools team to add an even to the extension api for when someone tries to edit and save a source mapped file.
Why wouldn't updating the live image be as simple as
"resource.setContent" with the new processed content and a sourcemap.
The problem with the scenario right now is that I believe
onResourceContentCommitted is called after resource.setUpdate. In the
case of files that needed to be re-generated, it would need to be
called before. So you need something like
onBeforeResourceContentCommitted.
> and probably not interesting anyway. More practical and interesting would be
> dedicated extension panels for editing artifacts that are meaningful to
> developers at the level of these languages.
Why not in the existing Scripts/Source panel? Devtools already has 2
panels that present an editor and file-like heirarchy in a side panel.
What about a plugin point for the editor in the Scripts panel? That
way someone could inject an ace/orion/codemirror editor and do other
cool stuff like auto-complete. I would write an extension for it if
there was a plugin point. I might even volunteer to write the plugin
point if you guys aren't already working on something like that.
On Wed, Jul 25, 2012 at 1:22 PM, John J Barton wrote:
> On Tue, Jul 24, 2012 at 5:55 PM, Ryan Ackley wrote:
>> Yes, right now it's unfeasible but with sourcemaps it seems trivial for
>> the devtools team to add an even to the extension api for when someone tries
>> to edit and save a source mapped file.
> Isn't that the event we already have, onResourceContentCommitted? I guess
> that editing the source files (eg in coffeescript, Less) should work just as
> well as js/css sources.
> Updating the live image is quite another matter, since devtools has no idea
> how the source and the live image are related. Mapping changes in the live
> image, eg editing via the Elements and Styles panel, would be very difficult
> and probably not interesting anyway. More practical and interesting would be
> dedicated extension panels for editing artifacts that are meaningful to
> developers at the level of these languages.
> jjb
On Wed, Jul 25, 2012 at 9:48 PM, Vsevolod Vlasov <vse...@google.com> wrote:
> Ryan, could you please share the message you were answering to here? It
> doesn't seem to have reached the mailing list.
> On Wed, Jul 25, 2012 at 2:26 PM, Ryan Ackley <ryanack...@gmail.com> wrote:
>> Why wouldn't updating the live image be as simple as
>> "resource.setContent" with the new processed content and a sourcemap.
>> The problem with the scenario right now is that I believe
>> onResourceContentCommitted is called after resource.setUpdate. In the
>> case of files that needed to be re-generated, it would need to be
>> called before. So you need something like
>> onBeforeResourceContentCommitted.
>> > and probably not interesting anyway. More practical and interesting
>> > would be
>> > dedicated extension panels for editing artifacts that are meaningful to
>> > developers at the level of these languages.
>> Why not in the existing Scripts/Source panel? Devtools already has 2
>> panels that present an editor and file-like heirarchy in a side panel.
>> What about a plugin point for the editor in the Scripts panel? That
>> way someone could inject an ace/orion/codemirror editor and do other
>> cool stuff like auto-complete. I would write an extension for it if
>> there was a plugin point. I might even volunteer to write the plugin
>> point if you guys aren't already working on something like that.
On Wednesday, July 25, 2012 3:26:30 AM UTC-7, Ryan Ackley wrote:
> Why wouldn't updating the live image be as simple as > "resource.setContent" with the new processed content and a sourcemap.
Because the resource is source, eg a Less file.
> The problem with the scenario right now is that I believe > onResourceContentCommitted is called after resource.setUpdate. In the > case of files that needed to be re-generated, it would need to be > called before. So you need something like > onBeforeResourceContentCommitted.
Well right now I think only JS can be edited anyway, but the entire Resoure/UISourceCode system is in flux.
Ultimately the user will be editing source, eg JS or CoffeeScript. When they save, listeners to onResourceContentCommitted get called. Those listeners can 1) save the source, eg to disk/cloud/etc and 2) process the source, eg live update JS or compile to JS then live update JS. So it seems like the event is already available right?
> > and probably not interesting anyway. More practical and interesting > would be > > dedicated extension panels for editing artifacts that are meaningful to > > developers at the level of these languages.
> Why not in the existing Scripts/Source panel? Devtools already has 2 > panels that present an editor and file-like heirarchy in a side panel.
Sorry I should have said "dedicated extensions for editing such artifacts". Extension authors may choice to use the Source panel or another panel.
> What about a plugin point for the editor in the Scripts panel? That > way someone could inject an ace/orion/codemirror editor and do other > cool stuff like auto-complete. I would write an extension for it if > there was a plugin point. I might even volunteer to write the plugin > point if you guys aren't already working on something like that.
Jan Keromnes is working on this, but it's orthogonal to the issues above. ace/orion/codemirror don't compile CoffeeScript/Less/SASS either.
> Ultimately the user will be editing source, eg JS or CoffeeScript. When they
> save, listeners to onResourceContentCommitted get called. Those listeners
> can 1) save the source, eg to disk/cloud/etc and 2) process the source, eg
> live update JS or compile to JS then live update JS. So it seems like the
> event is already available right?
I think we're on the same page. To clarify, I think there is a subtle
but technically relevant difference in the way things are handled
right now. I could be wrong but I believe the current event gets
called after it's successfully updated in the Web Inspector backend.
This won't work for Coffeescript since we would need to capture the
event before it's sent to the backend so we could turn it into
JavaScript before it tries to update the backend. This is what I was
getting at with an 'onBeforeResourceContentCommitted' event.
On Thu, Jul 26, 2012 at 3:54 AM, johnjbarton <johnjbarton....@gmail.com> wrote:
> On Wednesday, July 25, 2012 3:26:30 AM UTC-7, Ryan Ackley wrote:
>> Why wouldn't updating the live image be as simple as
>> "resource.setContent" with the new processed content and a sourcemap.
> Because the resource is source, eg a Less file.
>> The problem with the scenario right now is that I believe
>> onResourceContentCommitted is called after resource.setUpdate. In the
>> case of files that needed to be re-generated, it would need to be
>> called before. So you need something like
>> onBeforeResourceContentCommitted.
> Well right now I think only JS can be edited anyway, but the entire
> Resoure/UISourceCode system is in flux.
> Ultimately the user will be editing source, eg JS or CoffeeScript. When they
> save, listeners to onResourceContentCommitted get called. Those listeners
> can 1) save the source, eg to disk/cloud/etc and 2) process the source, eg
> live update JS or compile to JS then live update JS. So it seems like the
> event is already available right?
>> > and probably not interesting anyway. More practical and interesting
>> > would be
>> > dedicated extension panels for editing artifacts that are meaningful to
>> > developers at the level of these languages.
>> Why not in the existing Scripts/Source panel? Devtools already has 2
>> panels that present an editor and file-like heirarchy in a side panel.
> Sorry I should have said "dedicated extensions for editing such artifacts".
> Extension authors may choice to use the Source panel or another panel.
>> What about a plugin point for the editor in the Scripts panel? That
>> way someone could inject an ace/orion/codemirror editor and do other
>> cool stuff like auto-complete. I would write an extension for it if
>> there was a plugin point. I might even volunteer to write the plugin
>> point if you guys aren't already working on something like that.
> Jan Keromnes is working on this, but it's orthogonal to the issues above.
> ace/orion/codemirror don't compile CoffeeScript/Less/SASS either.
On Wednesday, July 25, 2012 11:10:34 AM UTC-7, Ryan Ackley wrote:
> > Ultimately the user will be editing source, eg JS or CoffeeScript. When > they > > save, listeners to onResourceContentCommitted get called. Those > listeners > > can 1) save the source, eg to disk/cloud/etc and 2) process the source, > eg > > live update JS or compile to JS then live update JS. So it seems like > the > > event is already available right?
> I think we're on the same page. To clarify, I think there is a subtle > but technically relevant difference in the way things are handled > right now. I could be wrong but I believe the current event gets > called after it's successfully updated in the Web Inspector backend. > This won't work for Coffeescript since we would need to capture the > event before it's sent to the backend so we could turn it into > JavaScript before it tries to update the backend. This is what I was > getting at with an 'onBeforeResourceContentCommitted' event.
Ah, I see that we just have different ideas of "right now". The commit sequence changed on 'trunk' in the last month.
Anyway I suggest you create a small test case, try it on Canary, and open a bug report.
I often just have 'public' folder that mapped to a website, e.g. "mysite.dev/style.css" is "public/style.css" on a file system. I don’t really want to create configs. I just want to choose a base directory that matches mysite.dev.
On Jul 24, 2012, at 1:03 AM, ryanack...@gmail.com wrote:
> The toFile section specifies how it does saving from Chrome devtools. It iterates through the "from" regexes to match each resource url. If there is a match it converts it into a file using the "to" expression. It uses matching groups found with the "from" regex. The "to" path is relative to the base directory.
> The fromFile section is for live reload. It's relative to the base directory. It's basically the toFile section in reverse. It's optional because tincr will infer the file-to-url relationships from the toFile section. In some cases, the inference isn't good enough. For example, with RoR, it's common to use SASS and coffeescript. Because they are converted to css and javascript, you can't do auto-save but you can do live reload. In my example above, the fromFile section is necessary because of this.
It’s basically the same routes written twice. Wouldn’t it be better to just use boolean flags:
> I often just have 'public' folder that mapped to a website, e.g. "mysite.dev/style.css" is "public/style.css" on a file system. I don’t really want to create configs. I just want to choose a base directory that matches mysite.dev.
> On Jul 24, 2012, at 1:03 AM, ryanack...@gmail.com wrote:
>> Thanks for taking an interest Nikita. I forgot to add the docs for this. I will add it ASAP. In the meantime,
>> This is the one I used for testing. It's for RoR.
>> The toFile section specifies how it does saving from Chrome devtools. It iterates through the "from" regexes to match each resource url. If there is a match it converts it into a file using the "to" expression. It uses matching groups found with the "from" regex. The "to" path is relative to the base directory.
>> The fromFile section is for live reload. It's relative to the base directory. It's basically the toFile section in reverse. It's optional because tincr will infer the file-to-url relationships from the toFile section. In some cases, the inference isn't good enough. For example, with RoR, it's common to use SASS and coffeescript. Because they are converted to css and javascript, you can't do auto-save but you can do live reload. In my example above, the fromFile section is necessary because of this.
> It’s basically the same routes written twice. Wouldn’t it be better to just use boolean flags:
I just noticed "Auto-Refresh" and "Auto-Save" checkboxes, so I don’t really see any reason to have neither the fromFile section nor the boolean options.
Hi Nikita thanks for digging into it and giving me more feedback. Let
me clarify a few things. One of the core concepts behind tincr is that
I wanted there to be almost no configuration for the end user. You
choose the application type and then point it at your project's base
directory.
I only did a handful of project types for the initial release based on
the types of projects I work on and the way I work. When I do
development on static files, I use file:// urls so I didn't think of
it. File:// urls should just work with no configuration. Mapping a web
server url to a local directory seems like a common use case so I will
add that.
The tincr.json config is used as a fallback/catch-all project type.
The idea was that you could use this if you didn't feel like writing
the code for a new custom project type.
On Thu, Jul 26, 2012 at 11:39 PM, Nikita Vasilyev <m...@elv1s.ru> wrote:
> On Jul 26, 2012, at 5:25 PM, Nikita Vasilyev <m...@elv1s.ru> wrote:
>> I often just have 'public' folder that mapped to a website, e.g. "mysite.dev/style.css" is "public/style.css" on a file system. I don’t really want to create configs. I just want to choose a base directory that matches mysite.dev.
>> On Jul 24, 2012, at 1:03 AM, ryanack...@gmail.com wrote:
>>> Thanks for taking an interest Nikita. I forgot to add the docs for this. I will add it ASAP. In the meantime,
>>> This is the one I used for testing. It's for RoR.
>>> The toFile section specifies how it does saving from Chrome devtools. It iterates through the "from" regexes to match each resource url. If there is a match it converts it into a file using the "to" expression. It uses matching groups found with the "from" regex. The "to" path is relative to the base directory.
>>> The fromFile section is for live reload. It's relative to the base directory. It's basically the toFile section in reverse. It's optional because tincr will infer the file-to-url relationships from the toFile section. In some cases, the inference isn't good enough. For example, with RoR, it's common to use SASS and coffeescript. Because they are converted to css and javascript, you can't do auto-save but you can do live reload. In my example above, the fromFile section is necessary because of this.
>> It’s basically the same routes written twice. Wouldn’t it be better to just use boolean flags:
> I just noticed "Auto-Refresh" and "Auto-Save" checkboxes, so I don’t really see any reason to have neither the fromFile section nor the boolean options.
>> Anyway, I see config files as a step backward. The latest Autosave uses GUI for that. I’ve found it much more user friendly.
On Tue, Jul 24, 2012 at 5:55 PM, <ryanack...@gmail.com> wrote:
> Yes, right now it's unfeasible but with sourcemaps it seems trivial for
> the devtools team to add an even to the extension api for when someone
> tries to edit and save a source mapped file.
Isn't that the event we already have, onResourceContentCommitted? I guess
that editing the source files (eg in coffeescript, Less) should work just
as well as js/css sources.
Updating the live image is quite another matter, since devtools has no idea
how the source and the live image are related. Mapping changes in the live
image, eg editing via the Elements and Styles panel, would be very
difficult and probably not interesting anyway. More practical and
interesting would be dedicated extension panels for editing artifacts that
are meaningful to developers at the level of these languages.
On Wed, Jul 25, 2012 at 2:26 PM, Ryan Ackley <ryanack...@gmail.com> wrote:
> Why wouldn't updating the live image be as simple as
> "resource.setContent" with the new processed content and a sourcemap.
> The problem with the scenario right now is that I believe
> onResourceContentCommitted is called after resource.setUpdate. In the
> case of files that needed to be re-generated, it would need to be
> called before. So you need something like
> onBeforeResourceContentCommitted.
> > and probably not interesting anyway. More practical and interesting
> would be
> > dedicated extension panels for editing artifacts that are meaningful to
> > developers at the level of these languages.
> Why not in the existing Scripts/Source panel? Devtools already has 2
> panels that present an editor and file-like heirarchy in a side panel.
> What about a plugin point for the editor in the Scripts panel? That
> way someone could inject an ace/orion/codemirror editor and do other
> cool stuff like auto-complete. I would write an extension for it if
> there was a plugin point. I might even volunteer to write the plugin
> point if you guys aren't already working on something like that.
This is exactly what I've been looking for - nice work!
Is there anyway to debug it? I'm using the 'Http Web Server' configuration, have my root directory set and tincr indicates the project was loaded successfully, however, when I save .js change they aren't reflected in the source file. Not seeing any log entries in my console window.
> Tincr is a tool that arose from my own frustration with switching back and > forth between Chrome Developer Tools to do debugging and my text editor to > do coding. The idea behind Tincr is that you can save changes to your > original source file from within Chrome Developer Tools. In addition, Tincr > does auto-reloading of JavaScript and CSS changes made in other editors. > It was partly inspired by two projects
> I've used NPAPI to make the functionality self-contained in the extension. > It doesn't require a proxy server or a separate application to interact > with the file system. Even though it uses native code, it should work on OS > X, Windows, and Linux.
> I'm also trying to make it dead simple to configure for common web > development platforms. To give you a complete illustration, let's say > you're developing a Ruby on Rails web application. You would select "Ruby > on Rails" in the dropdown on the Tincr panel and then select the local > directory of your rails application. Once you've done that, Tincr knows > enough about how a RoR application is structured that if you made a change > inside of Chrome Developer Tools, it would be saved to the local file > equivalent. If you made a change to an application script or stylesheet > using TextMate or some other tool, the change would automatically be > reloaded in Chrome without refreshing the whole page
> It should "just work" for local files accessed at "file://" urls. It > currently doesn't do pre-processing of things like CoffeeScript, SASS, > LESS, etc. but I'm working on that right now.
> I'm trying to get it released on the Chrome Web Store but since it > contains an NPAPI plugin it's taking a while (it has been Pending Review > for 11 days now).
Hi Dennis, try re-selecting the root folder with the log checkbox
ticked. You should see some message from Tincr on the console stating
if it was able to match up the files running in the debugger with the
files on the filesystem. If there are no messages then the paths
aren't matching up. The root of your localhost path should correspond
to the root of the directory you select.
On Sun, Aug 26, 2012 at 12:14 AM, <dennis.bec...@gmail.com> wrote:
> Hi!
> This is exactly what I've been looking for - nice work!
> Is there anyway to debug it? I'm using the 'Http Web Server' configuration,
> have my root directory set and tincr indicates the project was loaded
> successfully, however, when I save .js change they aren't reflected in the
> source file. Not seeing any log entries in my console window.
> Thanks!
> On Friday, July 20, 2012 12:04:43 PM UTC-4, ryana...@gmail.com wrote:
>> Hi all,
>> I've just released the first version of my devtools extension called Tincr
>> (pronounced link "Tinker") :
>> Tincr is a tool that arose from my own frustration with switching back and
>> forth between Chrome Developer Tools to do debugging and my text editor to
>> do coding. The idea behind Tincr is that you can save changes to your
>> original source file from within Chrome Developer Tools. In addition, Tincr
>> does auto-reloading of JavaScript and CSS changes made in other editors.
>> I've used NPAPI to make the functionality self-contained in the extension.
>> It doesn't require a proxy server or a separate application to interact with
>> the file system. Even though it uses native code, it should work on OS X,
>> Windows, and Linux.
>> I'm also trying to make it dead simple to configure for common web
>> development platforms. To give you a complete illustration, let's say you're
>> developing a Ruby on Rails web application. You would select "Ruby on Rails"
>> in the dropdown on the Tincr panel and then select the local directory of
>> your rails application. Once you've done that, Tincr knows enough about how
>> a RoR application is structured that if you made a change inside of Chrome
>> Developer Tools, it would be saved to the local file equivalent. If you made
>> a change to an application script or stylesheet using TextMate or some other
>> tool, the change would automatically be reloaded in Chrome without
>> refreshing the whole page
>> It should "just work" for local files accessed at "file://" urls. It
>> currently doesn't do pre-processing of things like CoffeeScript, SASS, LESS,
>> etc. but I'm working on that right now.
>> I'm trying to get it released on the Chrome Web Store but since it
>> contains an NPAPI plugin it's taking a while (it has been Pending Review for
>> 11 days now).
Still no love. I'm going to go out on a limb and guess it has something to do with my setup: - I'm using Tomcat as my server - My server side application is Java based - The application context root is myapp - so the URL: is localhost:8080/myapp/index.html - the directory I map to is: /...bunch of dirs../myapp/src/main/webapp - index.html resides under the webapp directory - I'm guessing Tincr is looking for myapp/index.html - what do you think? - I'm going to try deploying my application to the root of Tomcat server, that way the URL will just be /index.html which would map to under the webapp directory.
On Sunday, August 26, 2012 3:47:27 PM UTC-4, Ryan Ackley wrote:
> Hi Dennis, try re-selecting the root folder with the log checkbox > ticked. You should see some message from Tincr on the console stating > if it was able to match up the files running in the debugger with the > files on the filesystem. If there are no messages then the paths > aren't matching up. The root of your localhost path should correspond > to the root of the directory you select.
> -Ryan
> On Sun, Aug 26, 2012 at 12:14 AM, <dennis...@gmail.com <javascript:>> > wrote: > > Hi!
> > This is exactly what I've been looking for - nice work!
> > Is there anyway to debug it? I'm using the 'Http Web Server' > configuration, > > have my root directory set and tincr indicates the project was loaded > > successfully, however, when I save .js change they aren't reflected in > the > > source file. Not seeing any log entries in my console window.
> > Thanks!
> > On Friday, July 20, 2012 12:04:43 PM UTC-4, ryana...@gmail.com wrote:
> >> Hi all,
> >> I've just released the first version of my devtools extension called > Tincr > >> (pronounced link "Tinker") :
> >> Tincr is a tool that arose from my own frustration with switching back > and > >> forth between Chrome Developer Tools to do debugging and my text editor > to > >> do coding. The idea behind Tincr is that you can save changes to your > >> original source file from within Chrome Developer Tools. In addition, > Tincr > >> does auto-reloading of JavaScript and CSS changes made in other > editors.
> >> I've used NPAPI to make the functionality self-contained in the > extension. > >> It doesn't require a proxy server or a separate application to interact > with > >> the file system. Even though it uses native code, it should work on OS > X, > >> Windows, and Linux.
> >> I'm also trying to make it dead simple to configure for common web > >> development platforms. To give you a complete illustration, let's say > you're > >> developing a Ruby on Rails web application. You would select "Ruby on > Rails" > >> in the dropdown on the Tincr panel and then select the local directory > of > >> your rails application. Once you've done that, Tincr knows enough about > how > >> a RoR application is structured that if you made a change inside of > Chrome > >> Developer Tools, it would be saved to the local file equivalent. If you > made > >> a change to an application script or stylesheet using TextMate or some > other > >> tool, the change would automatically be reloaded in Chrome without > >> refreshing the whole page
> >> It should "just work" for local files accessed at "file://" urls. It > >> currently doesn't do pre-processing of things like CoffeeScript, SASS, > LESS, > >> etc. but I'm working on that right now.
> >> I'm trying to get it released on the Chrome Web Store but since it > >> contains an NPAPI plugin it's taking a while (it has been Pending > Review for > >> 11 days now).
> >> It's open source and it's hosted on bitbucket.
- Could you add a notification in case the saving fails? Devtools Autosave <https://github.com/NV/chrome-devtools-autosave> does something like this which is extremely useful. This because otherwise there is always this strange feeling whether the changes have really been saved correctly (you know, readonly files, wrong Http server root folder etc....) Otherwise one has continuously to go and look whether everything is fine
Another thing I notices is that the auto-refresh worked on my MacBook with OSX Mountain Lion but didn't on Win7 (same Chrome release channel). Any suggestions what could be the problem??
> Tincr is a tool that arose from my own frustration with switching back and > forth between Chrome Developer Tools to do debugging and my text editor to > do coding. The idea behind Tincr is that you can save changes to your > original source file from within Chrome Developer Tools. In addition, Tincr > does auto-reloading of JavaScript and CSS changes made in other editors. > It was partly inspired by two projects
> I've used NPAPI to make the functionality self-contained in the extension. > It doesn't require a proxy server or a separate application to interact > with the file system. Even though it uses native code, it should work on OS > X, Windows, and Linux.
> I'm also trying to make it dead simple to configure for common web > development platforms. To give you a complete illustration, let's say > you're developing a Ruby on Rails web application. You would select "Ruby > on Rails" in the dropdown on the Tincr panel and then select the local > directory of your rails application. Once you've done that, Tincr knows > enough about how a RoR application is structured that if you made a change > inside of Chrome Developer Tools, it would be saved to the local file > equivalent. If you made a change to an application script or stylesheet > using TextMate or some other tool, the change would automatically be > reloaded in Chrome without refreshing the whole page
> It should "just work" for local files accessed at "file://" urls. It > currently doesn't do pre-processing of things like CoffeeScript, SASS, > LESS, etc. but I'm working on that right now.
> I'm trying to get it released on the Chrome Web Store but since it > contains an NPAPI plugin it's taking a while (it has been Pending Review > for 11 days now).
Thanks so much for the suggestions. You found a bug in the windows
version. I wasn't converting all "/" to "\" on Windows only the first
occurence. I'll be releasing a new version shortly to fix it.
I've created a separate google group for Tincr so my announcement
thread stops hijacking the devtools group :)
On Tue, Sep 4, 2012 at 5:04 AM, <juri.strumpfloh...@gmail.com> wrote:
> I'm using Tincr for a couple of days now and I love it so far.
> Just some suggestions.
> Could you add a notification in case the saving fails? Devtools Autosave
> does something like this which is extremely useful. This because otherwise
> there is always this strange feeling whether the changes have really been
> saved correctly (you know, readonly files, wrong Http server root folder
> etc....) Otherwise one has continuously to go and look whether everything is
> fine
> Another thing I notices is that the auto-refresh worked on my MacBook with
> OSX Mountain Lion but didn't on Win7 (same Chrome release channel). Any
> suggestions what could be the problem??
> Thx a lot
> On Friday, July 20, 2012 6:04:43 PM UTC+2, ryana...@gmail.com wrote:
>> Hi all,
>> I've just released the first version of my devtools extension called Tincr
>> (pronounced link "Tinker") :
>> Tincr is a tool that arose from my own frustration with switching back and
>> forth between Chrome Developer Tools to do debugging and my text editor to
>> do coding. The idea behind Tincr is that you can save changes to your
>> original source file from within Chrome Developer Tools. In addition, Tincr
>> does auto-reloading of JavaScript and CSS changes made in other editors.
>> I've used NPAPI to make the functionality self-contained in the extension.
>> It doesn't require a proxy server or a separate application to interact with
>> the file system. Even though it uses native code, it should work on OS X,
>> Windows, and Linux.
>> I'm also trying to make it dead simple to configure for common web
>> development platforms. To give you a complete illustration, let's say you're
>> developing a Ruby on Rails web application. You would select "Ruby on Rails"
>> in the dropdown on the Tincr panel and then select the local directory of
>> your rails application. Once you've done that, Tincr knows enough about how
>> a RoR application is structured that if you made a change inside of Chrome
>> Developer Tools, it would be saved to the local file equivalent. If you made
>> a change to an application script or stylesheet using TextMate or some other
>> tool, the change would automatically be reloaded in Chrome without
>> refreshing the whole page
>> It should "just work" for local files accessed at "file://" urls. It
>> currently doesn't do pre-processing of things like CoffeeScript, SASS, LESS,
>> etc. but I'm working on that right now.
>> I'm trying to get it released on the Chrome Web Store but since it
>> contains an NPAPI plugin it's taking a while (it has been Pending Review for
>> 11 days now).
Could you post this little tidbit of info on the docs.html page? The way it is explained here was quite helpful and could have saved me about 35 minutes of troubleshooting. Love the extension! Thanks a lot! - Scott
On Sunday, August 26, 2012 3:47:27 PM UTC-4, Ryan Ackley wrote:
> You should see some message from Tincr on the console stating > if it was able to match up the files running in the debugger with the > files on the filesystem. If there are no messages then the paths > aren't matching up. The root of your localhost path should correspond > to the root of the directory you select.
