Feature request: scripting support

[GoogleCodeExporter]

Feature request: scripting support

[GoogleCodeExporter]

Question: why not use Qt's built-in Javascript support? This would minimize the 
number of dependencies. Also, I 
understand that Qt makes it possible to expose any object to the scripting 
engine, as well as easily create GUI 
dialogs, etc. 

Original comment by [email protected] on 8 Feb 2009 at 4:01

[GoogleCodeExporter]

The attached patch implements (rudimentary, but working) LuaScripting.

The details are documented in the attached doc file (it's in the wiki format, 
so it
should be possible to put it onto this page if Jonathan likes this patch). 
Currently,
only the AfterTypeset hook is available (I hope someone with more knowledge 
about Lua
than me will code a log parser with it ;)) and only the current selection in 
the TW
window can be changed by scripts.

This obviously introduces new dependencies. On my Ubuntu Linux this could be
satisfied with
{{{
sudo apt-get install liblua-5.1-dev
}}}
Not sure about MacOS and Windows (here my guess is that you need to download
lua5_1_4_Win32_dll8_lib.zip from http://luabinaries.luaforge.net/download.html,
unpack it, put the files from the "include" directory into your <TW>/src folder 
to
compile and the dlls into the folder of your executable to run; if someone can
confirm this I'll update the BuildingOnWindows docs).

For the record, the following files were added and should hence get an "svn 
add":
{{{
  res/resfiles/scripts/
  res/resfiles/scripts/parseLaTeXLog.lua
  res/resfiles/scripts/toggleBold.lua
  src/LuaInterface.cpp
  src/LuaInterface.h
  src/LuaScript.cpp
  src/LuaScript.h
  src/ManageScriptsDialog.cpp
  src/ManageScriptsDialog.h
  src/ManageScriptsDialog.ui
}}}

Original comment by st.loeffler on 7 Jun 2009 at 1:30

Attachments:

• issue27-lua-scripting.diff
• [Lua Documentation.txt](https://storage.googleapis.com/google-code-attachments/texworks/issue-27/comment-2/Lua Documentation.txt)

[GoogleCodeExporter]

@Windows: Sorry, I forgot one detail. The zip file I mentioned for downloading
includes two .dll and two .lib files. We'll use the lua5.1.dll and lua5.1.lib. 
For
compiling and linking the application, you'll need the .lib file. Put it in a 
place
where you find it again (e.g. C:\texworks) and add the following line to 
TeXworks.pro
to the windows section (where you've made changes before if you followed the
BuildingOnWindows guide):
LIBS += C:/texworks/lua5.1.lib
(change the paths according to your setup).

Then you need to remove your C++ project files and rerun qmake

Original comment by st.loeffler on 8 Jun 2009 at 5:45

[GoogleCodeExporter]

Scripting looks very promising!

Just a thought: in order to minimize dependencies, instead of actually 
embedding a lua interpreter, how about 
running luatex with the --luaonly option? There are two advantages.

* First, no additional dependencies. Compiling TeXworks on non-Linux platforms 
is a chore as it is
* Second, luatex is installed by recent versions of MikTeX and TeXLive, so it's 
basically available everywhere, 
"for free". 

The idea would be to run lua scripts much like we now invoke tex & friends, 
with some conventions to trasnfer 
data from/to TeXworks. Here, we can follow what TextMate does on OSX:

* it sets a bunch of environment variables, e.g. the current file name, the 
working directory, the currently 
selected word, the current line, the position of the caret, etc.
* it provides a way to send input (e.g. the currently selected word) to stdin 
and specify what to do with stdout 
(e.g. show it in a separate file, insert it at the current position, display as 
a HTML page).
* finally, it uses a standard way (CocoaDialog) to put up a simple GUI (e.g. a 
dialog box or drop-down list) if 
necessary.

This is extremely effective. TextMate is, IMHO, very effective with Latex 
editing. Also, I suspect providing the 
above "glue" requires much less pervasive changes to the TeXWorks code.

Any thoughts?

Original comment by [email protected] on 9 Jun 2009 at 5:16

[GoogleCodeExporter]

As pointed out by Alain Delmotte, the patch I posted accidentally contained 
some Qt
4.5 features, making compilation impossible on many systems. This patch should 
also
work with Qt 4.3

Original comment by st.loeffler on 18 Jun 2009 at 4:54

Attachments:

• issue27-lua-scripting-qt43.diff

[GoogleCodeExporter]

Original comment by st.loeffler on 22 Aug 2009 at 3:29

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Due to some requests to support Lua, I've resurrected my original Lua 
implementation
to work with the new scripting framework (see attached patch). The result is 
shinier,
better, and (almost) as powerful as the QtScript scripting.

To use the new lua plugin, start by applying the patch. Then build Tw normally. 
Next run
qmake -t subdirs
make
qmake
to build the lua plugin. Finally copy the .dll/.so/.dylib file from
plugins/TwLuaPlugin to somewhere where Tw can find it (in my case, this was the
directory containing the executable/the working directory).

The good news: many more properties and methods are available now. If I 
understand it
correctly, all scriptable objects should be available in Lua now (subject to the
limitations mentioned below).

Any testing (in particular on non-Linux machines) is greatly appreciated!

Here a few technical/implementation-specific notes:
* The same things rearding installing the lua libs as mentioned above apply to 
this
patch.
* As mentioned, the lua code is contained in a plugin. This way, it doesn't 
have to
be loaded for people who don't want it/need it/have doubts about lua. This 
required
moving some classes from TWScriptable.* to TWScriptableInterface.* so the main 
app
and the plugin can share definitions
* Note that plugins must be built for the system they are run on (i.e., they 
have to
built separately for Windows, Linux, Mac, just as the Tw app itself). Also note 
that
plugins won't run with applications built with a different (lower) Qt version. 
This
shouldn't be a problem normally, though.
* The new files (to be svn add'ed in case this is comitted) are:
plugins/TwLuaPlugin/TwLuaPlugin.cpp, plugins/TwLuaPlugin/TwLuaPlugin.h,
plugins/TwLuaPlugin/TwLuaPlugin.pro, src/TWScriptableInterface.cpp,
src/TWScriptableInterface.h
* For the plugin to find some functions in the Tw executable (mostly related to 
meta
methods of the shared TWScript) it was necessary to add the new linker flag
QMAKE_LFLAGS += -Wl,--export-dynamic. This should work for all gnu-based 
linkers, but
I'm not sure how to acchieve the same thing for MSVC (I didn't test it yet). In 
case
linking fails because of this flag, simple comment it - everything should work 
fine,
but the lua plugin won't load.
* I had to make the TWScript::run method non-constant. This is because the lua
scripts modify the lua state at run-time.
* Lua scripts can access Tw via the global "TW" variable. It is the same as the
"target" variable in QtScript scripts.
* Lua scripts can return a value through the global "result" variable.
* Currently, only basic types (bool, int, double) and strings (QString) are
supported. Support for arbitrary QObjects should be added in the future, but 
ATM the
basic types should be enough for many nice applications
* Return values from methods are currently not supported
* Only properties/methods available through the meta object system are 
available in
Lua. I think these are all properties defined by Q_PROPERTY and all public 
slots, but
I'm not sure yet.

Original comment by st.loeffler on 20 Dec 2009 at 3:57

Attachments:

• issue-27_lua-plugin.diff

[GoogleCodeExporter]

Wow - that sounds very cool. I haven't looked at the implementation yet, but if 
it's able to access exposed 
properties and methods via the Qt meta objects, I think that's the right way to 
go. That should allow the bulk 
of the application to be scriptable via either language, for no extra effort or 
maintenance burden.

There are a few build issues I'll want to look into before committing this to 
the main repository; I have not 
tried building Lua on the Mac, for example (with luck, it'll be trivial!), and 
on Windows there'll be the issue 
that I have been static-linking Qt for my "release" builds, but that prevents 
dynamic plugin loading.

Overall, though, I think this sounds awesome, and I'll try to look at it more 
closely over the Christmas period. 
Thanks!

Original comment by [email protected] on 20 Dec 2009 at 4:09

[GoogleCodeExporter]

Attached is an updated version of the lua plugin patch. All comments from above 
still
apply. I improved the conversion of data between C and lua format, though. It 
is now
possible to pass arrays and hashes between C and lua. This is necessary e.g. 
for the
AfterTypeset hook, which requires (nested) lists. This patch replaces the 
previous one.

A few definitions:
*) array
On the C side of the code, this is a QVariantList with zero-based indexes
On the lua side, this is a table with the indices 1..n for n entries
*) hash
On the C side, this is a QVariantHash
On the lua side, this is a table with string keys and simple values (i.e., 
strings,
numbers, arrays, hashes; no functions, threads, and similar stuff that can't be
translated to C)

Original comment by st.loeffler on 21 Dec 2009 at 2:43

Attachments:

• issue-27_lua-plugin.diff

[GoogleCodeExporter]

And one more gimmick to play with. A plugin for Python (my personal favorite
scripting language).

BTW: I also attached a sample version of Jonathan's "Make Bold" script in lua 
and
python, respectively, for easy testing.

It works similar to the lua plugin. All the interfaces, files, directories,
principles etc. are the same. Both the 2.x and the 3.x series of Python should 
be
supported.

Notes:
* There are currently only build flags for *nix in the .pro file. The flags for
Mac/Windows will be similar, but as I don't know how the files are named 
exactly I
didn't include any statements. They should be fairly simple to find out, though.
* If you want/must use Python 2.x, be sure to define the PYTHON2 directive (by
QMAKE_CXXFLAGS += -DPYTHON2). Otherwise you will get some errors with int types
(which were superseded by long in 3.x)
* If you want/must use Python 3.x, the plugin compiles correctly, but Tw crashes
complaining about unresolved symbols PyUnicode_* (or if you run into similar 
problems
with 2.x), add QMAKE_CXXFLAGS += -DPy_UNICODE_WIDE to your plugin's .pro file. 
This
defines unicode characters (the predominant form for strings in 3.x) to be wide 
(i.e.
4 bytes). Whether this is necessary or not depends on how your python 
dll/so/dylib
was compiled (it is necessary on Ubuntu).

Original comment by st.loeffler on 23 Dec 2009 at 6:20

Attachments:

• issue-27_python-plugin.diff
• makeBold.lua
• makeBold.py

[GoogleCodeExporter]

Even more awesome - I know Python is pretty popular, and this is a great 
demonstration of how readily other 
scripting languages can be connected to the same base functionality.

One thing I've wondered about - I have not yet looked closely enough at either 
the Lua or the new Python 
support, so maybe I'm missing something - is the "TW" object you're exposing, 
corresponding to the QtScript 
"target". Was there a strong reason to use this name? Or do you think we should 
call it "TW" in QtScript as 
well? It would seem preferable to keep the naming consistent across languages 
if possible.

Note that in QtScript, there are two significant objects exposed to the script: 
"target", which is the active (TeX 
or PDF) document at the time the script is called, and "app", which is the 
texworks application object, for 
access to various "global" properties and methods that are not associated with 
the specific document. In the 
Lua/Python interfaces, I've only noticed the equivalent of "target".

Original comment by [email protected] on 23 Dec 2009 at 7:00

[GoogleCodeExporter]

Readily? Well, that depends on the POV ;). No, in principle you're right. The 
main
problem is to dig into the C API of the respective scripting language (which I 
did
not achieve so "readily" for Python ;))

Yeah, "TW" corresponds to "target". There is no particular reason to call it 
that.
IIRC, I originally called it that under the assumption that I'd actually 
implement
and interface to the Tw application in general. And I missed the "app" object
altogether, though it should be fairly simple to expose that, too.

So, in general, I'm totally in favor of having the same name in all scripting
languages. However, I'd prefer to somehow make a distinction in nomenclature 
between
"normal" variables/code in the respective scripting language and 
variables/objects
that relate directly to Tw. Apart from making target and app properties of some
module/object (which would require a little more work, and maybe doesn't work so
easily in QtScript), I'd suggest something like TwTarget (or TwContext) and 
TwApp.

Original comment by st.loeffler on 23 Dec 2009 at 7:16

[GoogleCodeExporter]

And yet another new version of the two plugins (lua+python). The attached 
patches
should be used instead of the previous ones.
Changes:
 * renamed target to TWTarget
 * added TWApp
 * moved moc-specific code to TWScript base class. This should make both maintenance
and adding new features/languages easier.
 * implemented proper handling of return values (of calls to TWTarget/TWApp methods)
 * added support for passing other QObject derived objects to the script (not the
other way round, though)
 * added new doParseHeader() methods to TWScript to simplify parsing of (text-based)
script files. This could be used for JSScript, too.
 * documentation (Doxygen compatible)
 * updated the sample scripts

BTW: I found out that methods don't need to be public symbols to be known to the
moc-system. Q_INVOKABLE should also do the trick (though I didn't try).

Original comment by st.loeffler on 26 Dec 2009 at 2:45

Attachments:

• issue-27_lua-plugin.diff
• issue-27_python-plugin.diff
• makeBold.py
• makeBold.lua

[GoogleCodeExporter]

I have committed both the Lua and Python plugins to the main repository, with 
slightly adapted interfaces; they 
seem to work as expected for me in simple tests here, at least. Have not yet 
tackled the full range of build 
issues, so I'm not posting new binaries just yet, but this is looking very 
promising.

Stefan, please take a look at the adaptations I made, and let me know if I've 
broken anything, or if you think they 
were unhelpful; by committing the patches in this form, I don't mean that this 
is the final word, it's just to give 
us something we can continue to refine.

(Note that I have changed the "target" and "app" objects in the QtScript 
implementation to be TWTarget and 
TWApp respectively, so existing scripts will need to be updated when a new 
build appears.)

Original comment by [email protected] on 2 Jan 2010 at 12:42

• Changed state: Started

[GoogleCodeExporter]

Looks fine at a quick glance.
A few things I noticed:
 * The python header should be included first (according to the python docs). So the
inclusion of "TWScript.h" should be moved down after it (this removes several
warnings from the build process; I haven't checked if it would have worked 
otherwise).
 * I think we should stick to Python 2.x for the time being (it's the one recommended
on the python page). And Python 3.x is not available from the repositories on 
older
*nix systems, AFAIK. This basically means commenting out the other lines in
TWPythonPlugin.pro for the time being. (we could also think about replacing the
preprocessor definition PYTHON2 by one for PYTHON3 (it's only used in the code 
once)).
 * It would be nice to have a preprocessor definition to hard-code the plugin path at
compile time, which is necessary for packaging (on *nix, the plugins should go 
in
/usr/lib/texworks/ instead of /usr/bin/plugins)

Original comment by st.loeffler on 2 Jan 2010 at 2:12

[GoogleCodeExporter]

Ok, I moved the TWScript.h header in the python plugin (requires using a 
different preprocessor symbol to 
detect the Mac environment, where the Python include path is different).

I had already eliminated the use of the PYTHON2 define; using Python's 
predefined PY_MAJOR_VERSION instead.

I've provided TW_PLUGINPATH as a definition that can be set in the .pro file 
(default is /usr/local/lib/texworks); 
also, you can now use an env var to override this at runtime.

Original comment by [email protected] on 2 Jan 2010 at 4:18

[GoogleCodeExporter]

Hi, this is great!

I started packaging the plugins for Ubuntu. During the process, I found that my
plugin code is not compatible with Qt < 4.5 The attached patch should partially 
fix
and partially work around this. It also adds some comments to TWPythonPlugin.pro
(explanations re. why pkg-config is not used, and an example of how one could 
use
Python 3.x, which will probably become the standard eventually).

Original comment by st.loeffler on 2 Jan 2010 at 5:00

Attachments:

• issue-27_qt43-compatibility.diff

[GoogleCodeExporter]

I just noticed while updating the building instructions that it would be nice 
to add
install information to the plugins' .pro files. Something like
    target.path = /usr/local/lib/texworks
    INSTALLS += target
would enable the user to simply say `sudo make install` when finished building 
to
place the plugin where it's supposed to be. This would spare him the need to 
manually
create folders and link libraries.

Of course this is only useful on *nix, so it should go in a conditional clause.

Original comment by st.loeffler on 2 Jan 2010 at 5:11

[GoogleCodeExporter]

Looks fine to me, committed as r.528.

Original comment by [email protected] on 2 Jan 2010 at 5:12

[GoogleCodeExporter]

And another compatibility issue. For whatever reason, in Qt 4.3 a QMetaMethod 
can't
be invoked directly. Instead, QMetaObject::invokeMethod has to be used.

The attached patch should fix this issue and also implement the suggestion 
above.

Original comment by st.loeffler on 2 Jan 2010 at 7:03

Attachments:

• issue-27_qt43-compatibility2.diff

[GoogleCodeExporter]

Thanks, committed this also.

Original comment by [email protected] on 2 Jan 2010 at 9:41

[GoogleCodeExporter]

And one more compatibility issue, this time it's Python 2.5 compatibility 
(which is
the default on older Linux releases such as Ubuntu Hardy and Jaunty):
 * The C type PyCObject was introduced in 2.6; before that (and still supported
later) is PyObject
 * The PyBytes_* functions were introduced only in 3.x (and exist as aliases in
2.6.x); before that, the PyString_* functions had to be used
 * I also added the -fno-strict-aliasing to avoid compilation warnings on all
systems. It might also be necessary in the future to add the "-Xlinker
-export-dynamic" compiler flag to support some extensions, but until this 
becomes a
real issue I think we should be fine the way it is now.

One more suggestion for the future:
It might be useful to add another header key for script files like "Tw-Version" 
to
specify the minimum Tw version required to run the script. ATM, this can only be
0.3.0 (possibly with an svn addition?), but in the future the API could change
between versions (most notably new functions could become available for 
calling).

Original comment by st.loeffler on 3 Jan 2010 at 1:11

Attachments:

• issue-27_python25-compatibility.diff

[GoogleCodeExporter]

Ok, committed this also.

Regarding versioning: yes, that's a good point, but I don't want to implement 
something like that yet. For the 
time being, I consider the scripting APIs to be entirely experimental, and 
there is no guarantee whatsoever of 
compatibility across revisions. Declaring a "minimum TW version" would imply 
that all future versions must 
continue to support all the same properties and functions, and I don't think we 
are ready to make that 
commitment. (For example, I just broke all existing QtScript scripts by 
changing "target" to "TWTarget" for 
uniformity across languages!)

When we have a stable version 0.4 that includes scriptability, that'll be a 
different situation, and people will 
be entitled to have much higher expectations for compatibility and stability. 
For now, the 0.3 versions are 
clearly stated to be "experimental" development code.

Original comment by [email protected] on 3 Jan 2010 at 2:26

[GoogleCodeExporter]

Great, Tw and both plugins now compile on all Ubuntu distros back to Hardy 
(I've put
them up on launchpad).

Speaking of the API change: I've updated the built-in scripts to reflect that 
(see
attached patch). I also added handling of general warnings to latexErrors.js 
(i.e.,
things like "LaTeX Warning: There were undefined references." or "Package babel
Warning: ...").

Original comment by st.loeffler on 3 Jan 2010 at 5:27

Attachments:

• issue-27_updated-scripts.diff

[GoogleCodeExporter]

Cool, thanks! Before we rush ahead with updating scripts, though, what would 
you think of modifying the APIs 
(for all three languages) so that we just provide a single TW object (or module 
or whatever) with the "target" and 
"app" objects as members of this?

I haven't really looked seriously at how easy this would be to implement, but 
from a scripter's point of view I 
think it'd be nice; we'd then have TW.app, TW.target, and perhaps additional 
members/objects in the future 
without further cluttering the global namespace. What do you think?

Original comment by [email protected] on 3 Jan 2010 at 5:34

[GoogleCodeExporter]

Yeah, introducing a global TW object would be possible (a little easier in Lua 
than
in Python, but both should work). While we're at it, we could also move the 
variable
"result" (used in Lua and Python to return values from the script) into it.

I've noticed a bug in the Lua plugin regarding the handling of tables. The 
attached
patch should fix this (without it, one can't use the AfterTypeset hook, e.g.).

One more thing: I'm not too happy about
TWScriptLanguageInterface::scriptFileSuffix(). As it is, Python scripts can 
come with
a variety of extensions in principle (.py, .pyc, .pyo, ...). Most of them are
compiled versions and are currently not supported, but that's not the point. I'd
prefer something like bool 
TWScriptLanguageInterface::canHandleScriptFile(QString
filename). This way, any plugin developer could decide how to best check this. 
And we
could provide a helper function which can be called from canHandleScriptFile() 
and
does exactly what is done ATM: check the extension against a given one.

Original comment by st.loeffler on 3 Jan 2010 at 6:10

Attachments:

• issue-27_fix-lua-table-handling.diff

[GoogleCodeExporter]

The attached patch implements a new TW meta object (in both Lua and Python). It
currently supports TW.target (the context), TW.app (the TWApp wrapper) and 
TW.result
(for a return value from the script).

Original comment by st.loeffler on 6 Jan 2010 at 12:05

Attachments:

• issue-27_TW-meta-object.diff

[GoogleCodeExporter]

>One more thing: I'm not too happy about
>TWScriptLanguageInterface::scriptFileSuffix()....

Yes, that's a good point. I've modified it to use a method canHandleFile(const 
QFileInfo& fileInfo), which can 
easily just check fileInfo.suffix() but could do something more complex if 
desired.

Original comment by [email protected] on 9 Jan 2010 at 2:22

[GoogleCodeExporter]

I've updated the script APIs to use a single global object "TW", with 
properties .target, .app, .result. Rather than 
your patch from comment 27, I'm creating the TW object within TWScript::run(), 
and then passing this to 
language-specific execute() methods; that way everyone is scripting via the 
exact same TW object, and it's 
only maintained in one place.

All three languages seem to be working OK with this; feedback welcome.

Of course, scripts now need updating again........

Original comment by [email protected] on 9 Jan 2010 at 7:31

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Your latest revisions broke (parts of) both Lua and Python scripting. The 
attached
patch should fix this.
Changes:
 * changed TWInterface::result from QVariant* to QVariant and made it writable - this
is necessary since both Lua and Python can't return values and hence have to set
TWInterface::result directly (through TW.result). Also, QVariant is always 
converted
to and from native data types of the respective script language, hence QVariant*
isn't supported (since QVariant is not derived from QObject).
 * removed a supernumerary lua_pop during clean-up which messed up the lua stack and
hence prevented Lua scripts to be run more than once.
 * Changed a parameter name to be more descriptive.

Note to all Lua/Python script developers:
Due to the latest API change, it is no longer possible to write something like:
TW.result = []
TW.result.append(...)
It doesn't give an error, but the result of the script will be an empty list.
Instead, write something like
result = []
result.append(...)
TW.result = result
This is necessary because the value of TW.result will be converted to a native 
data
type of the scripting language each time it is referenced. Without a set 
operation of
the form "TW.result = ..." it never gets converted back, though.

Original comment by st.loeffler on 10 Jan 2010 at 11:50

Attachments:

• issue-27_api-change-fixes.diff

[GoogleCodeExporter]

Oops, sorry for the breakage; these fixes are now applied - thanks.

Original comment by [email protected] on 10 Jan 2010 at 12:38

[GoogleCodeExporter]

New feature: Managing scripts.

Changes:
 * New "Manage Scripts" dialog which displays extended information about scripts
(depending on which information is available) and allows to disabled scripts
 * The filenames of the disabled scripts (relative to the scripts directory to work
with portable operation) is stored in the settings. Rationale: a user who 
installs a
new script generaly wants it to work (i.e., it should not be disabled by 
default).
Additionally, a user will normally install a script to use it, i.e. the 
majority of
the scripts will be enabled (hence the list of disabled scripts is much 
shorter).
 * There is a new method TWScriptManager::isScriptEnabled(TWScript*). Rationale: this
method is inherently a GUI property, not a property of the individual script. In
addition, it requires access to the settings, which means it needs to be linked
against TWApp. Putting this in TWScript would blow up the scripting plugins
needlessly (since they would need to be linked against TWApp and all its 
dependencies).
 * runScript as well as the AfterTypeset hook check if a script is enabled before
executing it
 * disabled scripts are displayed in the menu, but grayed out. Rationale: disabling
scripts should be considered a temporary/transient state. If the user decides 
that a
script is no longer needed at all it should be uninstalled. Besides, disabling
standalone scripts is not very useful, anyway. It's mainly provided for 
symmetry to
the hook scripts. This could easily be changed to not showing them at all, 
though,
which could produce empty menus, however, unless additional effort is put into 
it
(e.g. if all scripts in a directory are disabled, the directory would still 
show as
empty menu).

Note that I haven't yet checked the code (in particular the .ui file) for
compatibility for Qt < 4.5.

Original comment by st.loeffler on 17 Jan 2010 at 9:10

Attachments:

• issue-27_manage-scripts.diff

[GoogleCodeExporter]

As suspected my last patch was not compatible with Qt 4.3. The one attached here
should be.

Changes:
 * Replaced QFormLayout with QGridLayout (the former was introduced only in 4.4)
 * Renamed the layout to the generic gridLayout as 4.3 apparently doesn't obey given
names for layouts

Original comment by st.loeffler on 18 Jan 2010 at 10:30

Attachments:

• issue-27_manage-scripts.diff

[GoogleCodeExporter]

Many thanks, Stefan! I'd recently begun working on a Manage Scripts window, 
too, so I've just downloaded your 
patch and will compare the ideas. (Mine wasn't to the point of actually being 
complete, but I may have one or two 
things I'll merge into yours.)

I'm away from home with extremely intermittent connectivity just now, but I'll 
try to work on this off-line in the 
next few days.

Original comment by [email protected] on 20 Jan 2010 at 6:18

[GoogleCodeExporter]

I've committed a version of the Manage Scripts window.

Stefan, you'll see that much of this is directly taken from your patch, though 
I have adapted it in a few ways. 
Internally, there's an "enabled" flag on the scripts, as I think that makes for 
a simpler, more efficient 
implementation (but this is a runtime-only property, not stored in the script 
file; I'm using your idea of the list of 
disabled scripts, and initializing the property from that). The Manage Scripts 
window is non-modal, which I think 
is preferable. Disabled scripts are removed from the menu, to reduce clutter 
(especially for people who choose 
to disable whole groups of scripts that they are not currently using).

I've restored the earlier design of using two tabs for the two classes of 
script; I think this will be preferable as 
the number of scripts increases.

There are some further enhancements I'm thinking of adding; in particular, I 
want to make the Hooks list a 
hierarchy just like the Standalone scripts, so that people can organize them in 
folders. And then I want to add 
checkboxes to the folders so that entire subtrees of scripts can be switched on 
and off easily.

Not tested for portability or backward compatibility yet, so I expect there 
will be a few issues to tidy up. And of 
course further ideas for improvement are welcome. (Hmm, how about being able to 
double-click a script in the 
list to open it in an editor window?)

Original comment by [email protected] on 26 Jan 2010 at 1:04

[GoogleCodeExporter]

Looks good.

Non-modal is better, though it's a bit weird not to have at least an "OK" 
button to
close it.

About the tabs: wouldn't it be better to have the standalone scripts first? 
This is
probably just a matter of taste, but the standalone ones are what I think most 
people
would immediately associate with the term "script". Besides, there are many more
standalone scripts than hooks, at least ATM.

Adding a hierarchy for hooks shouldn't be too difficult, seeing that we already 
have
it for standalone scripts. In fact, the code may even get a little simpler. 
Disabling
whole folders is certainly a good idea, though it requires a bit more coding
(including semi-checked folders if only some scripts in it are enabled, etc.).

About compatibility: it's actually looking better than I thought. The one 
problem I
found so far is a Qt 4.3 issue:
In file included from src/ScriptManager.h:26,
                 from src/TWScriptable.cpp:23:
ui/ui_ScriptManager.h: In member function 'void 
Ui_ScriptManager::setupUi(QWidget*)':
ui/ui_ScriptManager.h:62: error: 'class QTreeWidget' has no member named
'setHeaderHidden'
ui/ui_ScriptManager.h:74: error: 'class QTreeWidget' has no member named
'setHeaderHidden'
The headerHidden property of ScriptManager.ui should be replaced by a call to
header()->hide() somewhere in the init() method.

About new features:
Opening the script in an editor should certainly be possible. Though it should
probably be the system's editor, to a built-in one (with built-in ones, we'd 
have to
do syntax highlighting, etc., and an external editor may be geared towards a 
specific
programming language). What would also be nice would be to enable drag-and-drop 
for
installing files, possibly even from the internet (i.e., drag a link to a 
script file
from the browser into the dialog/a specific folder to cause Tw to download the 
file
to the scripts folder). Also, it may be nice to be able to open the top-level 
scripts
folder (and possible one of the subfolders) directly from the dialog - possibly 
by
means of a context menu.

Original comment by st.loeffler on 26 Jan 2010 at 1:44

[GoogleCodeExporter]

I couldn't decide which I preferred to put first, so as you mentioned it, I've 
swapped them. :)

In r549, I've removed the use of setHeaderHidden, so hope that will help for 
backward compat; also fixed a 
Windows build issue, and made it actually remember the disabled list - I broke 
that just before committing the 
code, and hadn't noticed right away.

Original comment by [email protected] on 26 Jan 2010 at 3:58

[GoogleCodeExporter]

OK. There is one more compatibility issue. For some reason, QHeaderView must be
#include'd explicitly in ScriptManager.cpp (it's probably just forward-declared 
in
QTreeView in Qt < 4.5).

Original comment by st.loeffler on 26 Jan 2010 at 5:21

[GoogleCodeExporter]

Opening a file in an external editor is quite trivial (see attached patch, 
which also
contains the compatibility fix for Qt < 4.5).

I also played with the idea of dropping files onto the dialog to install, but
downloading files from the internet is far from trivial, it seems...

Original comment by st.loeffler on 30 Jan 2010 at 9:43

Attachments:

• issue-27_edit-script.diff

[GoogleCodeExporter]

Yes, this looks good - thanks.

I changed it to go directly via QDesktopServices rather than using the 
launchFile method on TWApp, as that was 
intended for script use and is dependent on the "allow system commands" 
preference, which I don't think we 
need to pay attention to here.

Original comment by [email protected] on 30 Jan 2010 at 7:20

[GoogleCodeExporter]

With respect to python scripting, is there an issue with importing modules? It 
keeps 
throwing an exception.  But I can import the module from the command line. So I 
know 
that the module exists.

I am trying to implement a script which updates gnome's recent documents list.  
I would 
like to this with python because the bindings are already written and it was 
the first 
that clearly had the ability to do what I wanted to do.

Original comment by [email protected] on 1 Mar 2010 at 1:03

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I can reproduce this problem. In particular, it isn't limited to the pygtk 
module,
but can be reproduced, e.g., with the built-in datetime module (by putting 
"import
datetime") in a python script file). I don't think it is affecting Windows, 
though
(testing welcome).

After a lot of research, I believe that this problem can be (partially) solved 
by the
attached patch. With it, all the symbols from the python lib are put into the 
global
scope so that they are accessible from the module (the problem only seems to 
occur
for modules that need to load additional shared libs). With it, datetime works 
as
expected. Curiously, pygtk works the first time, but fails afterwards with a "No
module named gdk" error. We'll need to investigate this further, but I believe 
it's
quite likely that this problem is specific to the (complicated?) nature/layout 
of pygtk.

Original comment by st.loeffler on 4 Mar 2010 at 8:27

Attachments:

• issue-27_export-all-symbols-from-plugins.diff

[GoogleCodeExporter]

Note that the patch posted above requires Qt >= 4.4 (Intrepid and above, I 
think).
Previous versions won't break, but the bug won't be fixed. This is a limitation 
of Qt
(the required method was added in 4.4).

Original comment by st.loeffler on 4 Mar 2010 at 8:29