Closed GoogleCodeExporter closed 8 years ago
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 msinisca...@gmail.com
on 8 Feb 2009 at 4:01
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:
@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
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 msinisca...@gmail.com
on 9 Jun 2009 at 5:16
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:
Original comment by st.loeffler
on 22 Aug 2009 at 3:29
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:
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 jfkth...@gmail.com
on 20 Dec 2009 at 4:09
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:
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:
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 jfkth...@gmail.com
on 23 Dec 2009 at 7:00
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
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:
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 jfkth...@gmail.com
on 2 Jan 2010 at 12:42
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
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 jfkth...@gmail.com
on 2 Jan 2010 at 4:18
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:
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
Looks fine to me, committed as r.528.
Original comment by jfkth...@gmail.com
on 2 Jan 2010 at 5:12
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:
Thanks, committed this also.
Original comment by jfkth...@gmail.com
on 2 Jan 2010 at 9:41
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:
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 jfkth...@gmail.com
on 3 Jan 2010 at 2:26
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:
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 jfkth...@gmail.com
on 3 Jan 2010 at 5:34
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:
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:
>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 jfkth...@gmail.com
on 9 Jan 2010 at 2:22
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 jfkth...@gmail.com
on 9 Jan 2010 at 7:31
[deleted comment]
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:
Oops, sorry for the breakage; these fixes are now applied - thanks.
Original comment by jfkth...@gmail.com
on 10 Jan 2010 at 12:38
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:
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:
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 jfkth...@gmail.com
on 20 Jan 2010 at 6:18
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 jfkth...@gmail.com
on 26 Jan 2010 at 1:04
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
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 jfkth...@gmail.com
on 26 Jan 2010 at 3:58
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
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:
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 jfkth...@gmail.com
on 30 Jan 2010 at 7:20
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 roesler....@gmail.com
on 1 Mar 2010 at 1:03
[deleted comment]
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:
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
Original issue reported on code.google.com by
id.algo....@gmail.com
on 31 Aug 2008 at 5:13