Developer mode

Submitted by jokr on Thu, 03/13/2014 - 03:26

Forums:

When you write a script if something is wrong with your script, and you want to debug or fix the problem, you have to re-add it via scripts manager... everytime...

It's a bit annoying. I think it could be more productive if we can directly edit the script file in xnotifier folder (in our profile).

Maybe a 'developer mode' option we can temporary activate, could scan this folder and apply change?

 

 

jeroen's picture

jeroen

Thu, 03/13/2014 - 05:20

I somehow get your irritation:
When you are a poor coder and need at least 101 corrections before you get it right... YEAH, I get it 8-)

For the rest of us the present status quo defines a clear separation between coding and testing. No need for nifty and unnecessary extra development workload for admin.

But of course, that is only my opinion.

jokr

Fri, 03/14/2014 - 03:09

Is it unconstructive condescension I feel it in your reply ?

 

I think most of the time when users want a new script or an update, they come on the forums and post a request. Often it turns out that it's tobwithu who does it.
And therefore the time he spend to write and test this script, is time he could spend doing something more important.

If you look in the scripts list, most (I think over 80% ) are written by tobwithu and the rest by few other script writers.

The ideal solution would be if users can write their own scripts.
But I also think they need to be encouraged to do it.

And a feature permitting to edit your script without having to reload it in scripts manager, stay relevant for me.

Just my opinion of poor coder.

RpD

Fri, 03/14/2014 - 04:02

I believe scripting requires quite some programming skill... and the complexity varies by the email provider ...it's not average users of X-Notifier that can write them, that's why a majority of the scripts are written by Tobwithu.

Also, after the scripts are added to X-Notifier, they are stashed in an extension folder, and then... in using X-Notifier, they're loaded into a working memory of the extension... so what you need is something to force a reload, as you've noticed... and re-adding via the scripts manager does this.

You -can- work on the scripts in the extension's folder... most programmers could locate that ...but I'm guessing you still need to restart the browser/extension to get it reloaded into working memory.  

So, you're asking for X-Notifier to include a script programming debug tool... which is not usually part of most finished product options. 

It would be handy though... as a 'developer mode', as you say... however, where would you put it?Perhaps in the Scripts add manager?  A button to 'Reload scripts'?  Not much different from re-adding the script.
The option doesn't really fit anywhere else.

 

jokr

Fri, 03/14/2014 - 08:14

I gave an exemple with an autoscan functionality that reload script when change is detected, but maybe it could be something that stop the use of the script loaded in the working memory and forcing to read directly from the script file instead.

Where to put it ?
If it's a per script setting, it could be a checkbox near each scripts names in the scripts manager.
if it's globally, the script manager window stay relevant.

But, this it's just suggestion, i don't know how things works.
Only tobwithu know what could be usefull, and, the better way to implement it.

CFBancroft's picture

CFBancroft

Fri, 03/14/2014 - 10:01

What IF, Tobwithu died due to car/motorcycle/walking/jogging accident,
then we will get ROYAL SCREW!

My suggest... do NOT bother by implement with X-notifier... just leave as is!

I think, need to NEW Add-ons plug in called? "Script editor for X-notifier"

Tobwithu can write new Add-ons? or you (jokr) can make one for us?
(or somebody on this earth will do it in future...)

Thanks, CFBancroft

 

RpD

Fri, 03/14/2014 - 13:21

Separate script editor will not force a reload within X-Notifier.
Script editing is easily accomplished with Notepad... they are just dumb text files.
Script writing/editing requires human interpretation of what the webmail login needs, so it's hard to auto-program.

We do have a "Scripts" script that scans Scripts area online to inform us of updates -online- in the Scripts area.
We don't have an auto-scan to reload the X-Notifier extension's scripts folder... most users don't go there ...how much program burden, usefulness is auto-scanning the extension scripts folder for most users?  
Most script writers can debug their scripts without too much trouble... it's "trial and error" coders (sorry) that need a tool to avoid simply re-adding the script.  It would be a convenience to have a button to reload the script I suppose... but it's only to avoid a couple mouse clicks.

If Tobwithu is unavailable... ALL the scripts are available to us, for someone skilled enough to update the scripts... and the program source code is available.

But... it doesn't hurt to ask, and Tobwithu will do or don't.

jeroen's picture

jeroen

Fri, 03/14/2014 - 21:45

Hear, hear.

RpD

Fri, 03/14/2014 - 23:34

I suspect I sometimes am... although I don't/didn't really program much. More like macros, app language, etc. 
And might be said of all programmers? ...else the only bugs would be the creepy crawly and spy kind. 
Always a range of skills.   >;}  

jokr

Sat, 03/15/2014 - 04:32

ok, I understand my mistake. I was totally wrong and come here full of naive, without knowing how to write a script.
Before testing, you have to write the code, and it take much more time than testing.
I see why its not usefull.

Thanks for your time.

tobwithu's picture

tobwithu

Sat, 03/15/2014 - 05:00

You can directly edit your script if you turn off Firefox's javascript cache.

http://kb.mozillazine.org/Nglayout.debug.disable_xul_fastload

jeroen's picture

jeroen

Sat, 03/15/2014 - 11:06

@tobwithu:
So do I understand correctly, we can either:
1. manually change/add these prefs in about:config
or
2. unpack the {37fa1426-b82d-11db-8314-0800200c9a66}.xpi and add a debug.js with those prefs in defaults\preferences? (is it necessary to re-pack the xpi then?)

/* debugging prefs */
pref("browser.dom.window.dump.enabled", true);
pref("javascript.options.showInConsole", true);
pref("javascript.options.strict", true);
pref("nglayout.debug.disable_xul_cache", true);
pref("nglayout.debug.disable_xul_fastload", true);

And of course return those prefs back to false when done debugging?

RpD

Sat, 03/15/2014 - 13:25

Clearing (javascript) cache?
There are some people suggesting that clearing the cache can work, although it seems newer versions of Firefox cache clearing will not clear the javascript cache... but there's a developer toolbar that might...
( https://addons.mozilla.org/en-US/firefox/addon/web-developer ).

http://www.neiland.net/blog/article/turn-off-firefox-caching-when-doing-...

Otherwise, you can type about:config in Firefox address bar, and set network.http.use-cache to false ...if I got that right.  There's another parameter when working offline...  browser.cache.offline.enable

jeroen's picture

jeroen

Sat, 03/15/2014 - 20:02

I tested this 'Otherwise' suggestion yesterday (replacing a script in the hidden xn folder) and it didn't work. Either I missed a step (I did restart FF) or it doesn't affect the javascript cache.

If the option using debug.js is valid (see my former post), admin could add a boolean debugging and set the prefs to debugging (true/false) in debug.js. Or he can set them to false there and to debugging (true/false) at a strategically better location. Then we can set debugging = true while developping/debugging a script (in init() - restart browser). Am I on the right path here? (Or should we code this.debugging = true)

I am feeling stupid, because as a former Java/C++ programmer I am struggling to understand the javascript 'this':
http://unschooled.org/2012/03/understanding-javascript-this/
http://javascriptweblog.wordpress.com/2010/08/30/understanding-javascrip...

RpD

Sat, 03/15/2014 - 22:10

(Well... from skimming those "this" links... apparently Javascript's "this" is not like Java's "this"... and, it's heavily dependent on context (where it occurs in the code).  Since the rest of that is not relevant? here, I'll return to Tobwithu's post...)

Javascript caching
Apparently, you can type about:config in Firefox's address bar... and then type:  nglayout   ...in the Search bar to see all the nglayout.etc... preferences.  If nglayout.debug.disable_xul_fastload exists (usually not, I think), set it to 'true' to -not- cache javascripts.

If it doesn't exist, then right-click somewhere in the preferences list, select 'New' from the pop-up menu, select "Boolean" for the type, enter nglayout.debug.disable_xul_fastload for the preference name, and set it to 'true' to -not- cache javascripts.

Note:  you may have to restart Firefox, and... setting 'true' may slow Firefox down significantly.

Then, when you're finished 'developing'...  you can right-click that preference and 'Reset' it, or just double-click it to toggle the value to 'false'.

If I have all that right.

LA's picture

LA

Thu, 02/12/2015 - 05:24

Just in case somebody is looking for the same Development Mode for Chrome script development - I've found the following solution - just place your javascript into script's folder (on my Mac this is /Users/<myuserid>/Library/Application Support/Google/Chrome/Default/Extensions/cdfjbkbddpfnoplfhceolpopfoepleco/3.4.6_0/js/scripts/) and add it into list.json located at the same folder. That's it. You can modify the script there and there is no need to add/delete it again just to test it.