texworks - Project Hosting on Google Code

Today 1 min ago issue 27 (Feature request: scripting support) commented on by st.loeffler - 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) 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) 11 min ago Building (Notes on building TeXworks on various distributions.) Wiki page edited by st.loeffler - Revision r525 Scripting plugins on Ubuntu/Debian Edited wiki page through web user interface. Revision r525 Scripting plugins on Ubuntu/Debian Edited wiki page through web user interface. 27 min ago BuildingOnWindowsMinGW (Guide to building TeXworks on Windows XP using MinGW) Wiki page edited by st.loeffler - Revision r524 Instructions to build the Lua plugin Edited wiki page through web user interface. Revision r524 Instructions to build the Lua plugin Edited wiki page through web user interface. 41 min ago issue 243 (Opening new instance from commandline can fail, or even open...) commented on by jfkthame - Sorry, I forgot to comment here, but did commit the patch (modified slightly) as r.502. FYI, one "gotcha" in the Windows part of the code is that it is unsafe in Qt to write code like cds.lpData = fi.absoluteFilePath().toLocal8Bit().data(); SendMessageA(hWnd, WM_COPYDATA, 0, (LPARAM)&cds); because the temporary QByteArray returned by QString::toLocal8Bit() will go out of scope at the end of the statement, and therefore the pointer returned by the data() method becomes invalid before the call to SendMessageA() actually happens! We have to assign to a local QByteArray variable and then call data() on this, so that the buffer is guaranteed to remain valid until after the SendMessageA() call. Sorry, I forgot to comment here, but did commit the patch (modified slightly) as r.502. FYI, one "gotcha" in the Windows part of the code is that it is unsafe in Qt to write code like cds.lpData = fi.absoluteFilePath().toLocal8Bit().data(); SendMessageA(hWnd, WM_COPYDATA, 0, (LPARAM)&cds); because the temporary QByteArray returned by QString::toLocal8Bit() will go out of scope at the end of the statement, and therefore the pointer returned by the data() method becomes invalid before the call to SendMessageA() actually happens! We have to assign to a local QByteArray variable and then call data() on this, so that the buffer is guaranteed to remain valid until after the SendMessageA() call. 52 min ago issue 246 (Follow focus) commented on by jfkthame - I understood the request as meaning that the PDF view would automatically switch pages/scroll (and perhaps highlight the relevant section?) as needed to follow the current cursor position in the source, not necessarily for more precise location. This seems like it should be feasible, though exactly how it'll "feel" in practice is a bit unclear to me. I understood the request as meaning that the PDF view would automatically switch pages/scroll (and perhaps highlight the relevant section?) as needed to follow the current cursor position in the source, not necessarily for more precise location. This seems like it should be feasible, though exactly how it'll "feel" in practice is a bit unclear to me. 57 min ago issue 264 (Auto-hide output panel does not reclose after fixing errors) Status changed by jfkthame - Fixed in r.523. Status: Fixed Fixed in r.523. Status: Fixed 58 min ago r523 (improve handling of auto-hide option (issue 264)) committed by jfkthame - improve handling of auto-hide option ( issue 264 ) improve handling of auto-hide option ( issue 264 ) 74 min ago issue 264 (Auto-hide output panel does not reclose after fixing errors) commented on by jfkthame - Hmm. Yes, that makes sense. The "auto-hide" behavior remembers whether the output panel was open when the job began, and if so, it doesn't close it. The idea was that if you've deliberately opened it, then it should stay open. However, in this scenario it's open not because you deliberately chose to open it, but only because of the error on the previous run. So I can see why you'd expect it to automatically close again if the next run is error-free. I think we can improve this by changing the logic slightly: instead of recording whether the output panel was open at the start of the run, it should be recording whether it was opened by an explicit user action, or automatically due to a Typeset command. Hmm. Yes, that makes sense. The "auto-hide" behavior remembers whether the output panel was open when the job began, and if so, it doesn't close it. The idea was that if you've deliberately opened it, then it should stay open. However, in this scenario it's open not because you deliberately chose to open it, but only because of the error on the previous run. So I can see why you'd expect it to automatically close again if the next run is error-free. I think we can improve this by changing the logic slightly: instead of recording whether the output panel was open at the start of the run, it should be recording whether it was opened by an explicit user action, or automatically due to a Typeset command. 4 hours ago issue 267 (Editor: different font size for complex characters) reported by write.alex.mail - What steps will reproduce the problem? 1. Complex character sets such as for example Arabic script often need larger font sizes to be legible. 2. When using both latin and complext script in one text one has to either set everything to a rather large font in the editor or use a normal font size which leaves the complex script to remain not legible. What is the expected output? What do you see instead? It would be a great feature to set different font sizes for standard and complex script in the editor. What version of the product are you using? On what operating system? Version 0.1 r432 Windows 7 What steps will reproduce the problem? 1. Complex character sets such as for example Arabic script often need larger font sizes to be legible. 2. When using both latin and complext script in one text one has to either set everything to a rather large font in the editor or use a normal font size which leaves the complex script to remain not legible. What is the expected output? What do you see instead? It would be a great feature to set different font sizes for standard and complex script in the editor. What version of the product are you using? On what operating system? Version 0.1 r432 Windows 7 13 hours ago issue 263 (TeXworks 0.3 (r.511) "experimental" does not run on Tiger (O...) commented on by jfkthame - Ok, I've figured out why this is - it was built with gcc 4.2 (the default compiler on Snow Leopard), and that produces code that won't run on 10.4. For the next build, I'm intending to use gcc 4.0, which should allow better backward compatibility. (At some point in the not-too-distant future, I expect I'll give up trying to support 10.4. But I'm aiming to keep it alive at least until the next "stable" release, which will include the major new features currently in progress such as scripting support.) Ok, I've figured out why this is - it was built with gcc 4.2 (the default compiler on Snow Leopard), and that produces code that won't run on 10.4. For the next build, I'm intending to use gcc 4.0, which should allow better backward compatibility. (At some point in the not-too-distant future, I expect I'll give up trying to support 10.4. But I'm aiming to keep it alive at least until the next "stable" release, which will include the major new features currently in progress such as scripting support.) 13 hours ago issue 27 (Feature request: scripting support) Status changed by jfkthame - 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.) Status: Started 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.) Status: Started 13 hours ago r522 (added Lua and Python plugins (from Stefan's patches)) committed by jfkthame - added Lua and Python plugins (from Stefan's patches) added Lua and Python plugins (from Stefan's patches) 13 hours ago r521 (add support for scripting language plugins (based on Stefan'...) committed by jfkthame - add support for scripting language plugins (based on Stefan's patches) add support for scripting language plugins (based on Stefan's patches) Yesterday 41 hours ago r520 (refactoring script support to allow plugins, from Stefan's L...) committed by jfkthame - refactoring script support to allow plugins, from Stefan's Lua & Python patches refactoring script support to allow plugins, from Stefan's Lua & Python patches Last 7 days Dec 30, 2009 issue 266 (Save File Error) changed by st.loeffler - This has already been reported ( issue 256 ) and was (hopefully) fixed in r500. This will be included in the next Windows build. Until that is published, you could also build Tw yourself - see the wiki guides for that. Status: Duplicate This has already been reported ( issue 256 ) and was (hopefully) fixed in r500. This will be included in the next Windows build. Until that is published, you could also build Tw yourself - see the wiki guides for that. Status: Duplicate Dec 30, 2009 issue 256 (Save document error on "All files (.)") commented on by st.loeffler - Issue 266 has been merged into this issue. Issue 266 has been merged into this issue. Dec 30, 2009 issue 266 (Save File Error) reported by ConfuciusSaid - What steps will reproduce the problem? 1. Open a file, type something. 2. Save File as 1.asy or other extensions not listed. 3. You have to select ., then it says "file 1.asy. cannot be created. What is the expected output? What do you see instead? When the user select ., the system can accept the extension the user provided without add additional * extension. What version of the product are you using? On what operating system? the latest version on Windows Xp Please provide any additional information below. What steps will reproduce the problem? 1. Open a file, type something. 2. Save File as 1.asy or other extensions not listed. 3. You have to select ., then it says "file 1.asy.* cannot be created. What is the expected output? What do you see instead? When the user select ., the system can accept the extension the user provided without add additional * extension. What version of the product are you using? On what operating system? the latest version on Windows Xp Please provide any additional information below. Dec 29, 2009 Building (Notes on building TeXworks on various distributions.) Wiki page commented on by rey.olivier - In Ubuntu, I just downloaded the Debian package compiled by Stefan Löffler and it works very well (Karmic). Thanks for that. In Ubuntu, I just downloaded the Debian package compiled by Stefan Löffler and it works very well (Karmic). Thanks for that. Dec 29, 2009 issue 265 (Feature Request: keyboard shortcut for the tags window) reported by roesler.lucas - It would be nice to have keyboard access to the document outline found displayed by selecting Window>Show>Tags. This is related to: http://code.google.com/p/texworks/issues/detail?id=17 It would be nice to have keyboard access to the document outline found displayed by selecting Window>Show>Tags. This is related to: http://code.google.com/p/texworks/issues/detail?id=17 Dec 29, 2009 issue 264 (Auto-hide output panel does not reclose after fixing errors) reported by roesler.lucas - What steps will reproduce the problem? 1. Make sure the option "Auto-hide output panel unless errors occur" is selected in preferences. 2. Start with the output panel closed. 3. Try to compile a document containing a tex error, such as a missing $. 4. Output panel opens as it should. 5. Fix the error and recompile the document. What is the expected output? The output panel should close. What do you see instead? It remains open. What version of the product are you using? Version 0.3 (r.514) On what operating system? Ubuntu Karmic Please provide any additional information below. What steps will reproduce the problem? 1. Make sure the option "Auto-hide output panel unless errors occur" is selected in preferences. 2. Start with the output panel closed. 3. Try to compile a document containing a tex error, such as a missing $. 4. Output panel opens as it should. 5. Fix the error and recompile the document. What is the expected output? The output panel should close. What do you see instead? It remains open. What version of the product are you using? Version 0.3 (r.514) On what operating system? Ubuntu Karmic Please provide any additional information below. Dec 29, 2009 r519 (support Context header attribute in scripts; support hierarc...) committed by jfkthame - support Context header attribute in scripts; support hierarchical Scripts menu based on subdirectories of scripts folder support Context header attribute in scripts; support hierarchical Scripts menu based on subdirectories of scripts folder Dec 28, 2009 r518 (project changes for better backward compatibility on mac os ...) committed by jfkthame - project changes for better backward compatibility on mac os x project changes for better backward compatibility on mac os x Dec 28, 2009 r517 (padding for combobox in toolbar, macosx + qt4.6 issue (still...) committed by jfkthame - padding for combobox in toolbar, macosx + qt4.6 issue (still has problems drawing the menu) padding for combobox in toolbar, macosx + qt4.6 issue (still has problems drawing the menu) Dec 28, 2009 r516 (explicitly link with zlib on mac (needed for qt 4.6 build)) committed by jfkthame - explicitly link with zlib on mac (needed for qt 4.6 build) explicitly link with zlib on mac (needed for qt 4.6 build) Dec 28, 2009 r515 (add padding to toolbars, needed with qt4.6 on mac) committed by jfkthame - add padding to toolbars, needed with qt4.6 on mac add padding to toolbars, needed with qt4.6 on mac Dec 28, 2009 issue 263 (TeXworks 0.3 (r.511) "experimental" does not run on Tiger (O...) reported by jens.tra...@t-online.de - On my Apple computer with powerpc processor and operating system Leopard (OS X 10.5.8) TeXworks runs as expected. But on Tiger it does not run (TeXworks.crash.log): Host Name: my-power-mac-g5 Date/Time: 2009-12-28 11:25:25.521 +0100 OS Version: 10.4.11 (Build 8S165) Report Version: 4 Command: TeXworks Path: /Volumes/HD_1F_Software/Library/Software/TeXworks/experimental/TeXworks.app/Contents/M acOS/TeXworks Parent: WindowServer [64] Version: 0.3 (r.511) (0.3 (r.511)) PID: 252 Thread: Unknown Link (dyld) error: Symbol not found: ___stack_chk_guard Referenced from: /Volumes/HD_1F_Software/Library/Software/TeXworks/experimental/TeXworks.app/Contents/M acOS/TeXworks Expected in: /usr/lib/libSystem.B.dylib On my Apple computer with powerpc processor and operating system Leopard (OS X 10.5.8) TeXworks runs as expected. But on Tiger it does not run (TeXworks.crash.log): Host Name: my-power-mac-g5 Date/Time: 2009-12-28 11:25:25.521 +0100 OS Version: 10.4.11 (Build 8S165) Report Version: 4 Command: TeXworks Path: /Volumes/HD_1F_Software/Library/Software/TeXworks/experimental/TeXworks.app/Contents/M acOS/TeXworks Parent: WindowServer [64] Version: 0.3 (r.511) (0.3 (r.511)) PID: 252 Thread: Unknown Link (dyld) error: Symbol not found: ___stack_chk_guard Referenced from: /Volumes/HD_1F_Software/Library/Software/TeXworks/experimental/TeXworks.app/Contents/M acOS/TeXworks Expected in: /usr/lib/libSystem.B.dylib Dec 27, 2009 issue 260 ([Enhancement] Display script description in status bar) Status changed by jfkthame - Looks like an excellent idea, thanks. Committed as r514. Status: Fixed Looks like an excellent idea, thanks. Committed as r514. Status: Fixed Dec 27, 2009 r514 (show script description in status bar (patch from Stefan, is...) committed by jfkthame - show script description in status bar (patch from Stefan, issue 260 ) show script description in status bar (patch from Stefan, issue 260 ) Dec 27, 2009 r513 (added Afrikaans translation (Jannie Hofmeyr); ensure Mac bui...) committed by jfkthame - added Afrikaans translation (Jannie Hofmeyr); ensure Mac build has /usr/texbin in default paths added Afrikaans translation (Jannie Hofmeyr); ensure Mac build has /usr/texbin in default paths Dec 26, 2009 issue 252 (epstopdf crashes and no figures from an eps input are in the...) commented on by dingytao - Actually I have the same problem. Then I tried to run epstopdf in command line, it works fine. I changed the file name to %name_converted_to.pdf and then run Tw, it works. But if I run directly I just got blank image from the on the fly converting. Is this a bug?? Actually I have the same problem. Then I tried to run epstopdf in command line, it works fine. I changed the file name to %name_converted_to.pdf and then run Tw, it works. But if I run directly I just got blank image from the on the fly converting. Is this a bug?? Dec 26, 2009 issue 262 (My New Year wishlist for Texworks.) reported by zhouming1027 - After installing MikeTeX 2.8 and trying the texworks, I have the following wish list for the new year: 1. code folding; 2. customizable shortcuts; 3. a project manager which gives the tree form of files and also the outline of the working file. After installing MikeTeX 2.8 and trying the texworks, I have the following wish list for the new year: 1. code folding; 2. customizable shortcuts; 3. a project manager which gives the tree form of files and also the outline of the working file. Dec 26, 2009 AdvancedTypesettingTools (How to add popular advanced typesetting engines to TeXworks) Wiki page added by st.loeffler - Revision r512 Created wiki page through web user interface. Revision r512 Created wiki page through web user interface. Dec 26, 2009 issue 261 (Scripts) commented on by st.loeffler - Note: To use scripts, you need at least Tw 0.3 (the current development version at the time of writing). To install scripts, put them in the Tw scripts folder. Simply click on "Show Scripts Folder" in the "Scripts" menu of Tw (alternatively, navigate to the "scripts" folder in your Tw configuration folder by hand; see TipsAndTricks on the wiki to locate it). Then, click on "Update Scripts" in the "Scripts" menu of Tw (or restart Tw). Note: To use scripts, you need at least Tw 0.3 (the current development version at the time of writing). To install scripts, put them in the Tw scripts folder. Simply click on "Show Scripts Folder" in the "Scripts" menu of Tw (alternatively, navigate to the "scripts" folder in your Tw configuration folder by hand; see TipsAndTricks on the wiki to locate it). Then, click on "Update Scripts" in the "Scripts" menu of Tw (or restart Tw). Dec 26, 2009 issue 261 (Scripts) reported by st.loeffler - I open this issue for people to post their scripts here (for lack of a better way). I start by adding a script to inline bibliographies. When submitting papers to journals, they typically want all data contained in one single file (the .tex file) - they don't support (external) BibTeX files. The attached script opens the .bbl file associated with the currently open .tex file and copies its contents to the current cursor position. Note that this script saves the file before opening the .bbl file. This can lead to a "Save File" dialog. This is necessary as this is the only way I could think of right now to ensure that we're not working on a new (unsaved) document, which would cause problems. I open this issue for people to post their scripts here (for lack of a better way). I start by adding a script to inline bibliographies. When submitting papers to journals, they typically want all data contained in one single file (the .tex file) - they don't support (external) BibTeX files. The attached script opens the .bbl file associated with the currently open .tex file and copies its contents to the current cursor position. Note that this script saves the file before opening the .bbl file. This can lead to a "Save File" dialog. This is necessary as this is the only way I could think of right now to ensure that we're not working on a new (unsaved) document, which would cause problems. Dec 26, 2009 issue 27 (Feature request: scripting support) commented on by st.loeffler - 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). 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). Last 30 days Dec 26, 2009 issue 260 ([Enhancement] Display script description in status bar) commented on by st.loeffler - The attached patch displays the description in the status bar (I didn't get tooltips to work properly). In addition, it also deactivates the "Manage Scripts" menu item for now. Up until now, it simply does nothing (not even display a message), which can be irritating. The attached patch displays the description in the status bar (I didn't get tooltips to work properly). In addition, it also deactivates the "Manage Scripts" menu item for now. Up until now, it simply does nothing (not even display a message), which can be irritating. Dec 26, 2009 issue 260 ([Enhancement] Display script description in status bar) reported by st.loeffler - For better navigation (especially in the case of many scripts) the description text should be displayed somewhere. This is especially so if users download scripts developed by others so that they get a general idea of what the script does without having to try to comprehend the code. Since the "Manage Scripts" dialog is not available yet, tooltips or a text in the status bar would be nice. For better navigation (especially in the case of many scripts) the description text should be displayed somewhere. This is especially so if users download scripts developed by others so that they get a general idea of what the script does without having to try to comprehend the code. Since the "Manage Scripts" dialog is not available yet, tooltips or a text in the status bar would be nice. Dec 23, 2009 issue 27 (Feature request: scripting support) commented on by st.loeffler - 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. 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. Dec 23, 2009 issue 27 (Feature request: scripting support) commented on by jfkthame - 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". 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". Dec 23, 2009 issue 27 (Feature request: scripting support) commented on by st.loeffler - 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). 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). Dec 23, 2009 issue 259 (Persistent preferences) commented on by st.loeffler - I suspect you changed the spell checking language from the menu. This is intended to work on a per-window basis and is not stored. To change the global default value, please use the preferences dialog. This may seem a bit confusing and is a known problem (see issue 89). As for the configuration file, this is located in ~/.config/TUG/TeXworks.conf I suspect you changed the spell checking language from the menu. This is intended to work on a per-window basis and is not stored. To change the global default value, please use the preferences dialog. This may seem a bit confusing and is a known problem (see issue 89). As for the configuration file, this is located in ~/.config/TUG/TeXworks.conf Dec 22, 2009 issue 259 (Persistent preferences) reported by richard....@stampless.co.uk - What steps will reproduce the problem? 1. Change spelling preference to none from en-US 2. Close TeXworks 3. Open TeXworks 4. Spelling preference is en-US What is the expected output? What do you see instead? Spelling choice doesn't persist. What version of the product are you using? On what operating system? Version 0.3 (r.511) on Ubuntu 9.10, installed from 0.3.0~svn511-karmic1 using synapticSet Please provide any additional information below. I can't find a TeXworks configuration file anywhere on my system even though preference changes such as editor font and typesetting are persistent. I searched the system for files named Texworks (including hidden files) and I checked the folder ~/.TeXworks. All I could find there were the four folders (completion, configuration, scripts and translations) and their files. What steps will reproduce the problem? 1. Change spelling preference to none from en-US 2. Close TeXworks 3. Open TeXworks 4. Spelling preference is en-US What is the expected output? What do you see instead? Spelling choice doesn't persist. What version of the product are you using? On what operating system? Version 0.3 (r.511) on Ubuntu 9.10, installed from 0.3.0~svn511-karmic1 using synapticSet Please provide any additional information below. I can't find a TeXworks configuration file anywhere on my system even though preference changes such as editor font and typesetting are persistent. I searched the system for files named Texworks (including hidden files) and I checked the folder ~/.TeXworks. All I could find there were the four folders (completion, configuration, scripts and translations) and their files. Dec 21, 2009 issue 27 (Feature request: scripting support) commented on by st.loeffler - 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) 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) Dec 20, 2009 issue 27 (Feature request: scripting support) commented on by jfkthame - 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! 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! Dec 20, 2009 issue 27 (Feature request: scripting support) commented on by st.loeffler - 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. 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. Dec 20, 2009 issue 258 (unable to execute; the program ".exe" was not found; Typese...) commented on by st.loeffler - Unfortunately, it is not possible to include the TeX programs. For this, there are distributions that handle that very well. In fact, it's not only the programs themselves (which probably aren't that large; I didn't check), but thousands of packages. The complete distros are > 1GB, which you probably don't want to download each time with an editor (no worries, you don't need it all; those distros come with efficient ways of letting you install just what you need). FYI: the most popular TeX distributions for Windows are MiKTeX (http://miktex.org/) and TeXLive (http://www.tug.org/texlive/). You can get the typesetting progs from there. However, we may be able to improve the information Tw presents the user. For this, could you give a little more details? What error did appear in your case? What paths did you find? Where exactly occured the windows/unix problem? Unfortunately, it is not possible to include the TeX programs. For this, there are distributions that handle that very well. In fact, it's not only the programs themselves (which probably aren't that large; I didn't check), but thousands of packages. The complete distros are > 1GB, which you probably don't want to download each time with an editor (no worries, you don't need it all; those distros come with efficient ways of letting you install just what you need). FYI: the most popular TeX distributions for Windows are MiKTeX (http://miktex.org/) and TeXLive (http://www.tug.org/texlive/). You can get the typesetting progs from there. However, we may be able to improve the information Tw presents the user. For this, could you give a little more details? What error did appear in your case? What paths did you find? Where exactly occured the windows/unix problem? Dec 19, 2009 issue 172 (paste does not work) commented on by ashinpan - Ah, yes. What river22ali reminds me something. I use KMFL input method keyboards to input diacritics. Then this bug may have something to do with scim. Perhaps scim not compatible with TeXworks? Ah, yes. What river22ali reminds me something. I use KMFL input method keyboards to input diacritics. Then this bug may have something to do with scim. Perhaps scim not compatible with TeXworks? Dec 19, 2009 issue 258 (unable to execute; the program ".exe" was not found; Typese...) reported by kccheung.mit - What steps will reproduce the problem? 1. fresh install 2. try to typeset using any processing tool 3. error window appears 4. go to typesetting path preferences, try to edit a default path What is the expected output? What do you see instead? is it possible for the tex executables to be bundled in? i didn't expect to have to get them from elsewhere. also, would be nice to at least be able to edit the paths to fix the usual windows/unix forward/back-slash nonsense. better yet, have the windows install come with the paths in windows compatible format... What version of the product are you using? On what operating system? 0.2.3 r.466 on win7 Please provide any additional information below. What steps will reproduce the problem? 1. fresh install 2. try to typeset using any processing tool 3. error window appears 4. go to typesetting path preferences, try to edit a default path What is the expected output? What do you see instead? is it possible for the tex executables to be bundled in? i didn't expect to have to get them from elsewhere. also, would be nice to at least be able to edit the paths to fix the usual windows/unix forward/back-slash nonsense. better yet, have the windows install come with the paths in windows compatible format... What version of the product are you using? On what operating system? 0.2.3 r.466 on win7 Please provide any additional information below. Dec 19, 2009 TeXworks-Mac-0.3r511.zip (experimental TeXworks development build for Mac OS X - v0....) file uploaded by jfkthame - Labels: OpSys-OSX Labels: OpSys-OSX Dec 19, 2009 TeXworks-w32-0.3r511.zip (experimental TeXworks development build for Windows (zip a...) file uploaded by jfkthame - Labels: OpSys-Windows Labels: OpSys-Windows

issue 27 (Feature request: scripting support) commented on by st.loeffler - 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.

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.

Today

Yesterday

Last 7 days

Last 30 days