Re: I can´t run lyx 2.0.0 alpha 1
Marcelo Acuña wrote: >>> I have download alpha 1, >> configure, compile and install without problem. >>> But when I run it get: >>> >>> lyx-2.0.0.a1: symbol lookup error: lyx-2.0.0.a1: >> undefined >>> symbol: _ZN11QVectorData4freeEPS_i >>> >>> I have debian lenny with g++ 4.3.2, qt 4.6.2. >>> >>> Regards >> Usually, you use a different run-time version of Qt as the >> one you used in the compilation. >> >> Vincent > > I have only one qt installed. > Regards > Marcelo Have you done a system update after building LyX? Then you've linked against a Qt version which is not available any more on your system after your update. Peter
Re: How do I use toggle-dialog?
Rob Oakes wrote:
> Hi Vincent,
>
>> However, did you add the following to GuiView::build() ?
>>
>> if (name == "testmod")
>> return createGuiTestMod(*this);
>>
>> Vincent
>
> No, I had not. Thank you for the recommendation.
>
> I have now added the following to GuiView::build:
>
> ...
> Dialog * createGuiTestMod(GuiView & lv);
> ...
>
> if (name == "testmod")
> return createGuiTestMod(*this);
>
> I can still compile and use the program, but the little test dialog
> (which is really nothing than a few simple widgets that do very little)
> still does not appear as part of the Gui. When I activate the menu
> control, it still says:
>
> toggle-dialog testmod
>
> Nothing else happens. No other helpful errors, or segmentation faults
> to clue me in that something is happening, other than this:
>
> ** (:10208): CRITICAL **: atk_object_set_name: assertion
> `name != NULL' failed
>
> I've gone back and double checked my template code from GuiToc.cpp/.h,
> and I think that I have all of the needed methods. I'm not really sure
> what is causing the problem.
>
> Any other thoughts? Again, I really appreciate the help.
>
> Cheers,
>
> Rob
>
Search for "progress" in GuiView.cpp, and you will find that there is no
'|| name == "testmod" in 'case LFUN_DIALOG_SHOW: {'.
Peter
Re: How to build LyX using CMake?
Am Freitag, den 26.03.2010, 03:52 +0100 schrieb Uwe Stöhr: > Am 25.03.2010 22:13, schrieb Peter Kümmel: > > >> devenv lyx.sln /clean Release > > > > I'm not sure if denenv is part of the Express version of VC. > > It is not part, I'm now using this command with success: > > start lyx.sln /clean Release > > However, the "Release" option has no effect. MSVC is always started in the > debug configuration. I > manually have to reset its config to release mode. > > regards Uwe If you wanna build in the command line, try out the -G"NMake Makefiles" generator, it generates makefiles which could be used by nmake: cmake ..\trunk\development\cmake -G"NMake Makefiles" -Drelease=1 nmake But sometimes the command line calls are too long then the build stops, so I'm not sure if it works for lyx. Peter
Re: GuiHyperlink.cpp - compilation warning
Am Freitag, den 26.03.2010, 03:50 +0100 schrieb Uwe Stöhr: > Am 25.03.2010 22:17, schrieb Peter Kümmel: > > >> -G "Visual Studio 9.0" -Dnls=1 -DGNUWIN32_DIR="..." -Dmerge=0 > > This doesn't work, but this one: > > -G"Visual Studio 9 2008" -Dnls=1 -DGNUWIN32_DIR="..." -Dmerge=0 Calling cmake without arguments list all available generators (args which could be passed to -G) > > > And then open lyx.sln. > > I found now out how to decide if a debug or release build is created. There > are nevertheless 2 > issues left: > > - the files in LyX's lib folder are not copied to a "Resources" folder in the > folder where I have > build LyX. LyX therefore won't start when double-clicking on the lyx.exe. > (SCons automatically creates the Resources folder and update its contents > also automatically at the > end of the compilation.) Without installing it doesn't run out-off-the-box from the debugger. You have to set LYX_DIR_20x=/lib. You could add it global or in the Settings dialog for the lyx project which you must have marked as starting project. > > - How can I remerge and compile the po-files? > > --- > > For curiosity, I performed a full compilation of LyX using SCons and CMake. > The astonishing result > is that Cmake is only 2 minutes faster when using -Dmerge=0, when using > -Dmerge=1 it is much faster. > But this options produces compilation warnings as I already reported. If you are only interested in "does LyX compile" and you don't wanna debug merge=1 is enough. Most warnings could be ignored, they pop up because most libs are compiled as one file, then things are visible in other files which are not seen when compiled normally. Peter > thanks and regards > Uwe
Re: GuiHyperlink.cpp - compilation warning
Am Donnerstag, den 25.03.2010, 17:00 +0100 schrieb Abdelrazak Younes: > On 03/25/2010 03:38 PM, Uwe Stöhr wrote: > >>> Btw. After I run CMake, I opened the lyx.sln file. I then used the > >>> MSVC menu named "build". This successfully compiled LyX, but a debug > >>> version. What do have to change to compile a release version? > >> > >> There is a combo box at the top to select "Release" or "Debug" > > > > Hmm, the combo box has here only one entry "Release". But the > > compilation result is a debug version. (When I stad the lyx.exe, it > > requires the GtGuid.dll and not the QtGui.dll.) > > That's really weird. I have Debug, Release and RelWithDebInfo. Are you > sure you are looking into the right directory? > > Also, make sure your build directory is out of the source tree. > > > > > Can you please tell me you exact CMake build command including all > > options ? > > I don't have access to my Windows system right now but, out of memory, > it is: > > -G "Visual Studio 9.0" -Dnls=1 -DGNUWIN32_DIR="..." -Dmerge=0 > > That's all. And then open lyx.sln. > > Abdel
Re: How to build LyX using CMake?
Am Mittwoch, den 24.03.2010, 05:18 +0100 schrieb Uwe Stöhr: > > :: clean > devenv lyx.sln /clean Release I'm not sure if denenv is part of the Express version of VC. Peter > > > So the folder D:/LyXSVN/lyx-devel/lyx-windows-deps-msvc2008/bin that contains > the iconv.dll is > already part of the PATH. What am I doing wrong? > (I also tested out the CMake gui as proposed by Joost but without success.) > > > Besides this, there is another error: > > D:\LyXSVN\lyx-devel\compile-result>devenv lyx.sln /clean Release > The command "devenv" is either misspelled or could not be found > > I searched my whole PC and there is indeed no executable file named "devenv". > What do I have to install to have devenv? > > thanks and regards > Uwe
Re: How to build LyX using CMake?
Am Dienstag, den 23.03.2010, 04:34 +0100 schrieb Uwe Stöhr:
> I want to switch from SCons to CMake.
>
> Reading the file "INSTALL.cmake" I see that this file is outdated (it tells
> me that I should install
> MSVC 2005). Do we have a more recent description how to use CMake?
Sorry about it state of the file, you could use also msvc 2009.
> Besides this, in the "INSTALL.cmake" I read that i need "win32libs with the
> 'KDE on Windows'
> installer". Is this still the case?
>
> ---
>
> When I try to compile LyX using CMake, it stops with these error messages:
>
> CMake Error at modules/FindGNUWIN32.cmake:45 (message):
>Could NOT find GNUWIN32, please set GNUWIN32_DIR
> Call Stack (most recent call first):
>modules/LyXPaths.cmake:58 (find_package)
>CMakeLists.txt:38 (include)
> -- -- PACKAGE not versioned, to enable use -DUseVersionSuffix=1
> --
> -- All *.cpp files of a project are merged into two files, disable with
> -Dmerge=0
> --
> CMake Error at modules/FindQt4.cmake:1017 (message):
>Qt qmake not found!
You must have qmake in the PATH.
> Call Stack (most recent call first):
>CMakeLists.txt:187 (find_package)
>
>
> I had a look into "FindQt4" and see there this code:
>
> # check for qmake
> find_program(QT_QMAKE_EXECUTABLE NAMES qmake qmake-qt4 PATHS
>
> "[HKEY_CURRENT_USER\\Software\\Trolltech\\Qt3Versions\\4.0.0;InstallDir]/bin"
>"[HKEY_CURRENT_USER\\Software\\Trolltech\\Versions\\4.0.0;InstallDir]/bin"
>$ENV{QTDIR}/bin)
>
> Why are there two hardcoded paths as possible target?
>
>
> In this first try, I started CMake using the "build.bat" in the folder
> "~\lyx-devel\development\cmake"
> I'm using Qt 4.5.3 in this folder
> "~\lyx-devel\lyx-windows-deps-msvc2008\qt-4"
export PATH=lyx-devel\lyx-windows-deps-msvc2008\qt-4;%PATH%
cd I-build-cmake-here-folder
cmake ..\lyx-devel\development\cmake -G"Visual Studio 9 2008"
Should work.
Peter
>
> I guess I need to rename the Qt folder or set its path somewhere but don't
> know where. Or do I need
> to have the MSVC version of Qt 4.6.x installed?
>
> thanks and regards
> Uwe
Re: LyX 2.0 / Windows
Abdelrazak Younes wrote: > On 03/14/2010 09:01 PM, Joost Verburg wrote: > > Not everyone uses Firefox or OpenOffice, so I think we should not rely > > on the dictionaries installed by other applications. > > But what if they are already installed at LyX installation time? Quite > frankly, when I am on Windows, I hate having to install 3 different > dictionaries for OpenOffice, Firefox and Thunderbird... Couldn't we > optionally ask the user if she wants to reuse any such installed > dictionaries? We live in times with TeraByte disks, so why should we care about some duplicated installs, especially when it costs us much time to support more advanced solutions. Using the packages of other programs is an optimization and we should only optimize when in really hurts. Peter
Re: Simple cmake question
Kornel Benko wrote: > Am Freitag 12 März 2010 schrieb Peter Kümmel: >> /opt/local/lib is a directory only and I assume ENCHANT_LIBRARY should >> point to a existing library. >> >> Kornel's comment was about the cmake command which searches for the >> 'enchant' library in existing directories: >> find_library(ENCHANT_LIBRARY "enchant" "/usr/local/lib" "/usr/lib") >> >> So 'cmake -DENCHANT_LIBRARY=/opt/local/lib/libenchant.so' or something >> similar should work. >> >> But you could also patch the cmakefile then you don't have to type these >> lengthy command line. >> >> Peter >> > > Exactly. > > Kornel I've added the /opt path, it should work now without the additional command options. Peter
Re: Simple cmake question
BH wrote: > On Fri, Mar 12, 2010 at 1:25 PM, Kornel Benko wrote: >> Am Freitag 12 März 2010 schrieb Kornel Benko: >>> Am Freitag 12 März 2010 schrieb BH: I can't get cmake to recognize my enchant installation at /opt/local/. What cmake variable am I not setting correctly? BH >>> To compile, you need the development package. We are searching for include >>> files _and_ for libraries. (So e.g. for ubuntu this is: libenchant-dev + >>> libenchant1c2a) >>> >>> Kornel >>> >> Read again, I see the "unusual" path, therefore you have to patch the >> CMakeLists.txt. >> >> In trunk, look at line 228: >>... >>find_library(ENCHANT_LIBRARY "enchant" "/usr/local/lib" "/usr/lib") >> >> Here you may provide your path like this: >>find_library(ENCHANT_LIBRARY "enchant" "/usr/local/lib" "/usr/lib" >> "/opt/local/lib") >> >> Appropriate change also to find the include (provided it is >> "/opt/local/enchant") >>find_path(ENCHANT_INCLUDE_DIR "enchant++.h" PATHS /usr/local/include >> /usr/local/include/enchant /usr/include /usr/include/enchant >> /opt/local/enchant) > > Thanks. I used > > cmake -DENCHANT_LIBRARY=/opt/local/lib /opt/local/lib is a directory only and I assume ENCHANT_LIBRARY should point to a existing library. Kornel's comment was about the cmake command which searches for the 'enchant' library in existing directories: find_library(ENCHANT_LIBRARY "enchant" "/usr/local/lib" "/usr/lib") So 'cmake -DENCHANT_LIBRARY=/opt/local/lib/libenchant.so' or something similar should work. But you could also patch the cmakefile then you don't have to type these lengthy command line. Peter > -DENCHANT_INCLUDE_DIR=/opt/local/include/enchant > > and now it works. However, when cmake finishes, it now spits out this warning: > > WARNING: Target "LyX2.0" requests linking to directory > "/opt/local/lib". Targets may link only to libraries. CMake is > dropping the item. > > ... and then linking fails: > > Linking CXX executable ../bin/LyX2.0 > Undefined symbols: > "_enchant_dict_get_error", referenced from: > lyx::EnchantChecker::check(lyx::WordLangTuple const&)in EnchantChecker.o > "_enchant_dict_suggest", referenced from: > lyx::EnchantChecker::suggest(lyx::WordLangTuple const&, > lyx::docstring_list&)in EnchantChecker.o > "_enchant_broker_request_dict", referenced from: > lyx::EnchantChecker::Private::addSpeller(std::basic_string std::char_traits, std::allocator > const&)in > EnchantChecker.o > "_enchant_dict_free_string_list", referenced from: > lyx::EnchantChecker::suggest(lyx::WordLangTuple const&, > lyx::docstring_list&)in EnchantChecker.o > "_enchant_dict_check", referenced from: > lyx::EnchantChecker::check(lyx::WordLangTuple const&)in EnchantChecker.o > "_enchant_broker_get_error", referenced from: > lyx::EnchantChecker::Private::addSpeller(std::basic_string std::char_traits, std::allocator > const&)in > EnchantChecker.o > "_enchant_broker_free_dict", referenced from: > lyx::EnchantChecker::Private::~Private()in EnchantChecker.o > "_enchant_dict_add_to_session", referenced from: > lyx::EnchantChecker::accept(lyx::WordLangTuple const&)in > EnchantChecker.o > "_enchant_broker_free", referenced from: > ___tcf_0 in EnchantChecker.o > "_enchant_broker_init", referenced from: > __static_initialization_and_destruction_0(int, int)in EnchantChecker.o > "_enchant_dict_add", referenced from: > lyx::EnchantChecker::insert(lyx::WordLangTuple const&)in > EnchantChecker.o > "_enchant_dict_describe", referenced from: > lyx::EnchantChecker::Private::addSpeller(std::basic_string std::char_traits, std::allocator > const&)in > EnchantChecker.o > "_enchant_broker_dict_exists", referenced from: > lyx::EnchantChecker::hasDictionary(lyx::Language const*) constin > EnchantChecker.o > lyx::EnchantChecker::Private::addSpeller(std::basic_string std::char_traits, std::allocator > const&)in > EnchantChecker.o > ld: symbol(s) not found > collect2: ld returned 1 exit status > make[2]: *** [bin/LyX2.0] Error 1 > make[1]: *** [src/CMakeFiles/LyX2.0.dir/all] Error 2 > make: *** [all] Error 2 > > > What am I doing wrong? > > (Note: I can build lyx with enchant using autotools rather than cmake.) > > BH >
Re: Compile problem branch: cmake+boost+pcheaders.h
Vincent van Ravesteijn wrote: > When I try to compile branch with cmake I get the following error: > > pcheaders.h(41) : fatal error C1083: Cannot open include file: > 'boost/test/utils/nullstream.hpp': No such file or directory > > This is wat pcheaders.h says: > > # include > > This file really does not exist. > > Vincent > You could remove these lines. Which boost version does branch use? Now I realize I've not updated branch when I upgraded trunk. Peter
Re: offtopic blog
Am Freitag, den 05.02.2010, 12:54 -0500 schrieb Steve Litt: > On Friday 05 February 2010 02:39:29 Pavel Sanda wrote: > > Abdel, you're gonna be famous :) > > > > http://www.linuxtoday.com/infrastructure/2010020500435OSSW Maybe it's the time now to try it out by myself ;) Does it have a language heuristic which detects the used language automatically? I really hate it that Thunderbird doesn't switch to English from German when ALL words are wrong when I write English but the checker checks for German. It would be so easy to not only check for the selected language but also some others and then when in some of these other languages all errors, or something near 100%, are gone the spellchecker switches this language. Peter
Re: r33258 - in lyx-devel/trunk/src: . frontends frontends/qt4
Andre Poenitz wrote: > On Wed, Feb 03, 2010 at 06:27:06PM +0100, Peter Kümmel wrote: >> Peter Kümmel wrote: >>> Peter Kümmel wrote: >>>> Originally it was the Model-View-Controller pattern, so isn't a >>>> controller the perfect candidate for the central dispatcher? >>>> >>> Wouldn't it be best to completely unlink the model and view like in >>> attached image, found as figue 4-6 in >>> http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html >> Diving a little bit deeper into the Apple's docs I must admit: >> Documentation at it's best! >> Such docu I miss for Qt, most there is a extended doxygen API >> description only, no big-picture is given any where. >> >> By the way, being again off-topic-on-the wrong-list: >> Are there plans to create a "Qt Interface Builder" >> which exports .qib files? > > What's a .qib file? I only find http://filext.com/file-extension/QIP > which seems unrelated. > > Andre' > .qib is analog to .nib "NeXT Interface Builder". The Interface Builder of the Mac still uses the .nib extension; they still follow their "NS ideology": NSObject, NSString, ... Peter
Re: r33258 - in lyx-devel/trunk/src: . frontends frontends/qt4
Peter Kümmel wrote: > Peter Kümmel wrote: >> Originally it was the Model-View-Controller pattern, so isn't a >> controller the perfect candidate for the central dispatcher? >> > > Wouldn't it be best to completely unlink the model and view like in > attached image, found as figue 4-6 in > http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html Diving a little bit deeper into the Apple's docs I must admit: Documentation at it's best! Such docu I miss for Qt, most there is a extended doxygen API description only, no big-picture is given any where. By the way, being again off-topic-on-the wrong-list: Are there plans to create a "Qt Interface Builder" which exports .qib files? Peter
Re: r33258 - in lyx-devel/trunk/src: . frontends frontends/qt4
Abdelrazak Younes wrote: > On 02/03/2010 12:17 PM, Peter Kümmel wrote: >> Peter Kümmel wrote: >> >>> Originally it was the Model-View-Controller pattern, so isn't a >>> controller the perfect candidate for the central dispatcher? >>> >>> > > If we proceed as I suggested then that would be the result indeed: > > model: everything in src/, src/inset/ and src/math/ Here I would move model relevant code from src to src/model, then the binary would become a smaller project which onlx links to the essential parts. I would also introduce shared libraries which help to avoild circular dependencies between the libraries, especially when building Dlls on Windows, but maybe there is also a GCC flag to forbid such dependencies . > > view: all the different dialogs, including GuiView > > controller: GuiApp mainly, but also GuiView::dispatch(), as well Dialog, > GuiDialog and DialogView classes. I would not distribute the controller functionality to several classes. > >> Wouldn't it be best to completely unlink the model and view like in >> attached image, found as figue 4-6 in >> http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html >> > > At this point, this is becoming academic. What is especially important > is that the model is free of any GUI code. Then we can always cleanup > progressively the source code to have clearer separation between the > views and the controllers, but that is of lesser importance. Having several views (GUI/non-GUI) it is better to also send model's notifications through the controller. > > Abdel >
Re: r33258 - in lyx-devel/trunk/src: . frontends frontends/qt4
Peter Kümmel wrote: > > Originally it was the Model-View-Controller pattern, so isn't a > controller the perfect candidate for the central dispatcher? > Wouldn't it be best to completely unlink the model and view like in attached image, found as figue 4-6 in http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html Peter <>
Re: r33258 - in lyx-devel/trunk/src: . frontends frontends/qt4
Jean-Marc Lasgouttes wrote: > Abdelrazak Younes writes: >> As far as dispatch is concerned, my goal was to make >> GuiApp::dispatch() the first entry in the dispatch machinery instead >> of LyXFunc::dispatch() which should basically disappear... At the end, >> all the virtual interface in "src/frontend/" should disappear too. > > I could not care less about where is the main entry point as long as > there is a main entry point and everybody is not directly invoking > individual dispatch function. > > About putting it in GuiApp, why not, although most of the code there is > non-gui code. What could/should probably move is the default: case of > the big switch. Originally it was the Model-View-Controller pattern, so isn't a controller the perfect candidate for the cental dispatcher? > > Note that, with my latest changes, LyXFunc only has two member variables > left (those for saving cursor x/y). I would propose to move these > variables into Cursor (savedX, savedY). Would somebody object to that? > > Then there would not be a LyXFunc object anymore, but functions (or > static members). > > JMarc >
Re: r33258 - in lyx-devel/trunk/src: . frontends frontends/qt4
Andre Poenitz wrote: > On Tue, Feb 02, 2010 at 02:53:58PM +0100, Peter Kümmel wrote: >> Am Sonntag, den 31.01.2010, 14:29 +0100 schrieb Andre Poenitz: >>>> How do we proceed now ? >>> I think it's time to use signal/slots, this time in the right direction. >>> The buffer emits a message, possibly with an indication that it is >>> temporarily and the view (or the server...) connects to it. >>> >>> Andre' >> Does this also mean currently we have no clear Model/View design? > > Sort of. > > Right now the Gui is basically signaling the Core to change and the > Core pushes changes to the Gui. Which is pretty wrong. You mean the core knows the gui and calls gui-only functions to update the view? This would be indeed wrong. Where there attempts to fix this design? Or was the design OK in good old times and then somehow became wrong? Haven't Abdel tried to cleanup this? Shouldn't we do a cleanup/redesign at such places? Peter
Re: r33258 - in lyx-devel/trunk/src: . frontends frontends/qt4
Am Sonntag, den 31.01.2010, 14:29 +0100 schrieb Andre Poenitz: > > How do we proceed now ? > > I think it's time to use signal/slots, this time in the right direction. > The buffer emits a message, possibly with an indication that it is > temporarily and the view (or the server...) connects to it. > > Andre' Does this also mean currently we have no clear Model/View design? Peter
Re: Goals for alpha 1
José Matos wrote: > On Friday 29 January 2010 22:38:05 Peter Kümmel wrote: >> Read the "Table of contents" at >> http://wiki.lyx.org/LyX/NewInLyX20 >> >> most looks like "bug/missing-feature" fixing. This is maybe >> only my perception, but imagine a "non-hacker/user-only" reads >> this list, he would wonder why we've decided to name the next >> release "LyX 2.0". There is no "iPad" effect ;) >> >> Peter > > So I propose to rename it to 0.19 because we have always evolved and never > had > any real revolution. > > LyX 1.6.x is a different beast from 1.0.0 and yet you insist to have the same > initial number. The change to a new major number is longer overdue. > I don't insist on 2.0. I only think to make the jump to 2.0 now is without a reason. We missed the chance to name it 2.0 when releasing 1.6, so why should we do it now. Assume we introduce a new file-format,would we relase 3.0 then? But don't get me wrong, I don't care that much on the version number. I'm glad we don't start something like LyX 02.2010. Peter
Re: XML?
>
> So please, don't be shy, show me an example of this format :-)
>
> SteveT
>
It's really hard to find some examples!
Seems thy need a better marketing ;)
But there is a German blog with some code snips
http://www.luatex.de/
And find attached a luatex file from
http://code.google.com/p/mingyue
Peter
% De http://luatex.bluwiki.com/go/Use_a_TrueType_font
% Environnement : max_print_line=2048
% Changes TODO: feature (and script, lang) indexes shouldn't depend on the font.
% Addition TODO: all the other lookups, and script-specific shaping ...
\catcode`\~=11
\def\lua{\directlua0}
\lua{
dofile('l-table.lua')
function message(...)
n = select('#', ...)
for i = 1, n do
texio.write('term and log', tostring(select(i, ...)))
if i == n
then texio.write_nl('term and log', '')
else texio.write('term and log', ' ') end
end
if n == 0 then texio.write('term and log', '\string\n') end
end
function message_ln(...)
n = select('#', ...)
for i = 1, n do
texio.write('term and log', tostring(select(i, ...)))
if i ~= n then texio.write('term and log', ' ') end
end
end
verbose = 52134
function beverbose(n)
return node.has_attribute(n, verbose)
end
function beverboser(n)
return node.has_attribute(n, verbose) and node.has_attribute(n, verbose) >=2
end
function beverbosest(n)
return node.has_attribute(n, verbose) and node.has_attribute(n, verbose) >=3
end
function table.nentries(t)
local n = 0
for _, _ in pairs(t) do n = n + 1 end
return n
end
}
\attributedef\verbose=52134
\def\beverbose{\verbose=1\relax}% \relax needed because of the digit!
\def\beverboser{\verbose=2\relax}
\def\beverbosest{\verbose=3\relax}
\def\bequiet{\verbose=-1\relax}
\def\dumpnatfont{\lua{
message(table.serialize(
fontforge.to_table(fontforge.open(font.fonts[font.current()].filename))
))
}}
\def\dumptexfont{\lua{message(table.serialize(font.fonts[font.current()]))}}
\directlua0{
function loadtruetype(name, size)
fonttype = nil
filename = kpse.find_file(name,"opentype fonts")
if (filename)
then fonttype = 'opentype'
else filename = kpse.find_file(name, "truetype fonts")
end
if filename and not fonttype then fonttype = 'truetype' end
if fonttype then
if (size < 0) then size = (- 655.36) * size end
ttffont = fontforge.to_table(fontforge.open(filename))
if ttffont then
% HACK HACK HACK
local tweak_size
% if name == 'AdobeArabic-Regular' then tweak_size = true end
if ttffont.units_per_em == 2048 and fonttype == 'opentype'
then tweak_size = true end
if tweak_size then size = size / 2.048 end
f = { }
f.name = ttffont.fontname
f.fullname = ttffont.names[1].names.fullname
f.parameters = { }
f.designsize = size
f.size = size
direction = 0
f.parameters.slant = 0
f.parameters.space = size * 0.25
f.parameters.space_stretch = 0.3 * size
f.parameters.space_shrink = 0.1 * size
f.parameters.x_height = 0.4 * size
f.parameters.quad = 1.0 * size
f.parameters.extra_space = 0
f.characters = { }
local mag = size / ttffont.units_per_em
local scriptindex = { }
local langindex = { }
local featindex = { }
f.map = ttffont.map
f.features = { }
for _, otable in ipairs({ "gsub", "gpos" }) do
if ttffont[otable] then
for _, feat in ipairs(ttffont[otable]) do
if feat.features then
for _, ft in ipairs(feat.features) do
if ft.tag then
local tag = ft.tag
if not featindex[tag]
then featindex[tag] = table.nentries(featindex) + 1 end
f.features[tag] = f.features[tag] or { }
local f_tag = f.features[tag]
f_tag.table = otable
local scripts = ft.scripts
for _, screcord in ipairs(ft.scripts) do
local script = screcord.script
if not scriptindex[script] then
scriptindex[script] = table.nentries(scriptindex) + 1
end
f_tag[script] = f_tag[script] or { }
for _, lang in ipairs(screcord.langs) do
if not langindex[lang] then
langindex[lang] = table.nentries(langindex) + 1
end
f_tag[script][lang] = f_tag[script][lang] or { }
f_tag[script][lang].subtables
= f_tag[script][lang].subtables or { }
local f_st = f_tag[script][lang].subtables
for _, st in ipairs(feat.subtables)
do table.insert(f_st, st.name) end
f_tag[script][lang].flags = feat.flags
f_tag[script][la
Re: binding arguments to an int?
Am Samstag, den 30.01.2010, 01:54 +0100 schrieb Andre Poenitz:
> On Fri, Jan 29, 2010 at 10:44:03PM +0100, Peter Kümmel wrote:
> > When enabling the merged build (using cmake)
> > which essentially is a build of each lib as
> > one file, I get often compiler errors which
> > are mostly due to multiple defined symbols.
> >
> > But now it looks very strange to me in
> > socktools.cpp:
> >
> > int fd;
> > ...
> > // bind() gives the local address 'name' for 'fd', also creating
> > // the socket special file in the filesystem. bind() returns -1
> > // in case of error
> > if ((::bind (fd, reinterpret_cast(&addr), SUN_LEN(&addr)))
> > == -1) {
> >
> > the compiler says:
> > error: ‘int’ is not a class, struct, or union type
> > and I also wonder how arguments could be bind to a int.
> >
> > And why does it compile without the merge option?
> >
> > Does anyone have an explanation?
>
> Perhaps some funny #define fd something earlier.
>
> The canonical approach to debugging this is to get the preprocessed
> output of the compilation unit and cut it down...
>
> Andre'
It's a GCC bug, gcc resolves ::bind as boost::bind
Peter
Re: XML?
Am Samstag, den 30.01.2010, 00:30 +0100 schrieb Peter Kümmel: > just google for these to words. Lua and > JavaScript are very similar. First Google hit (here) is "JSON: The Fat-Free Alternative to XML": http://www.json.org/xml.html Peter
Re: XML?
Am Freitag, den 29.01.2010, 17:55 -0500 schrieb Steve Litt: > > Hi Peter, > > As a LyX user who often parses LyX native code in documents, programmatically > writes LyX native code, and uses Vim to change LyX native code, I have the > same reservations about lua as I do with XML -- it might make my job as a > user > a lot harder. Starting from your link I tried to find an example of luatex > and > couldn't. > > When the talk turns of embedding LUA within TeX, I start getting VERY > nervous. > XML is bad enough, but at least with an XML parser it parses down to > hierarchy > that could be reasonably parsed. Having looked at Javascript embedded HTML, > I'm concerned. > > Do you have more docuemntation with examples of Luatex? Your doubts are fully justified, I also couldn't find an example on the luatex site. Here is an example how Lua could be used within TeX http://luatex.bluwiki.com/go/Traversing_TeX_nodes Open a scope and enter the Lua scipt. I assume the script is simpler than all the <..> tags. > > Thanks > > SteveT > > Steve Litt > Recession Relief Package > http://www.recession-relief.US > Twitter: http://www.twitter.com/stevelitt
Re: XML?
Am Freitag, den 29.01.2010, 17:50 -0500 schrieb rgheck: > On 01/29/2010 05:18 PM, Peter Kümmel wrote: > > Again, maybe I'm too late, but: > > Is a switch to XML is really a good idea? > > > > The XML hype is over, we don't use Java, LyX > > doesn't run on a Application-Server, and we > > live now in a App/web-app world where Json > > is more common than XML. > > > > And living in the Latex world this means we should > > not use XML but the equivalent for Json in Tex: > > > > Lua. http://www.lua.org/ > > > > In future there is a Latex with an embedded script > > language > > > > http://www.luatex.org/ > > > > which we could use NOW for our needs. > > > > > What would help me here is to see a simple example of what the file > format would look like. Sorry for not posing an example. Here a link to a bibtex-like entry: http://www.lua.org/pil/10.1.html > > But I think part of the point of XML is its self-validating and highly > structured character. Yes, there is a huge infrastructure for XML. But the discussion is similar to "json xml", just google for these to words. Lua and JavaScript are very similar. > > Richard
Re: Goals for alpha 1
Am Freitag, den 29.01.2010, 22:55 +0100 schrieb Vincent van Ravesteijn:> > > > What revolution do you expect for 2.0 then ? (or are we back at the > XML-thing now ?) Read the "Table of contents" at http://wiki.lyx.org/LyX/NewInLyX20 most looks like "bug/missing-feature" fixing. This is maybe only my perception, but imagine a "non-hacker/user-only" reads this list, he would wonder why we've decided to name the next release "LyX 2.0". There is no "iPad" effect ;) Peter
XML?
Again, maybe I'm too late, but: Is a switch to XML is really a good idea? The XML hype is over, we don't use Java, LyX doesn't run on a Application-Server, and we live now in a App/web-app world where Json is more common than XML. And living in the Latex world this means we should not use XML but the equivalent for Json in Tex: Lua. http://www.lua.org/ In future there is a Latex with an embedded script language http://www.luatex.org/ which we could use NOW for our needs. We could use Lua internally in LyX as scripting languange (footprint: 100kB) and as file format similar to JSON: In a LyX document are function calls which are are bound to C++ functions. Loading a document is simply done by setting up the binding and to execute the script. Similar to SAX with XML, but much more readable and faster (for x86 there is a Just-In-Time compiler). Sure, we could export to some XML format, but we should not make XML the first-level LyX file format. Peter HTML book: http://www.lua.org/pil/
Re: Goals for alpha 1
Am Freitag, den 29.01.2010, 18:30 + schrieb José Matos: > On Friday 15 January 2010 19:42:30 Pavel Sanda wrote: > > José Matos wrote: > > > Any other opinions suggestions? > > > > - please do some definitive decision about version number now. > > i have asked about the opinions few days ago, whoever has something > > to say got his chance. the result was 2:1 for 1.7 so you have the > > royal choice :) Maybe I'm too late, but I vote for 1.7 because we have nothing essential new, all is "self-evident", we made evolutiona not a revolution. Peter
binding arguments to an int?
When enabling the merged build (using cmake)
which essentially is a build of each lib as
one file, I get often compiler errors which
are mostly due to multiple defined symbols.
But now it looks very strange to me in
socktools.cpp:
int fd;
...
// bind() gives the local address 'name' for 'fd', also creating
// the socket special file in the filesystem. bind() returns -1
// in case of error
if ((::bind (fd, reinterpret_cast(&addr), SUN_LEN(&addr)))
== -1) {
the compiler says:
error: ‘int’ is not a class, struct, or union type
and I also wonder how arguments could be bind to a int.
And why does it compile without the merge option?
Does anyone have an explanation?
Peter
Re: :frontend::ProgressViewWidget::settingsLayout missing
Am Mittwoch, den 06.01.2010, 21:41 +0100 schrieb Peter Kümmel: > Am Mittwoch, den 06.01.2010, 10:36 -0500 schrieb Manoj Rajagopalan: > > > > On Wednesday 06 January 2010 05:42:35 am Kornel Benko wrote: > > > Am Wednesday 06 January 2010 schrieb Jean-Marc Lasgouttes: > > > > "Vincent van Ravesteijn - TNW" writes: > > > > > Would the attached be something ? > > > > > > > > Still same error here (qt 4.2.3). > > > > > > > > JMarc > > > > > > Same with qt 4-4.3.1 (OpenSuSE 10.3) > > > > > > Kornel > > > > Same with qt 4.3.4 / KUbuntu 8.04 / i686 > > > > -- Manoj > > When the designer is only PITA, then we should drop the > ui file and make it by hand. > > Peter > I've disabled the dialog for Qt versions < 4.5. At least it should compile now. Peter
Re: About the new Debug Window
Am Mittwoch, den 06.01.2010, 10:56 +0100 schrieb Jean-Marc Lasgouttes: > Jürgen Spitzmüller writes: > > > Peter Kümmel wrote: > >> I've committed a patch: It's still a checkbox but with three states: it > >> toggles between all levels enabled, all disabled, and previous selected > >> levels. Hope it's perfect now ;) > > > > From an UI point of view, I'd very much prefer a combo or radio buttons > > instead. We do not use checkboxes this way in the LyX GUI until now, and I > > think we should keep the UI consistent. > > +1 > > Or we could have two normal buttons labelled 'select all' and 'deselect > all'. > > JMarc And a buttons 'select my selection'? Currently we manage three states. I think the current solution is ok. Peter
Re: About the new Debug Window
Am Mittwoch, den 06.01.2010, 10:46 +0100 schrieb Jürgen Spitzmüller: > Peter Kümmel wrote: > > I've committed a patch: It's still a checkbox but with three states: it > > toggles between all levels enabled, all disabled, and previous selected > > levels. Hope it's perfect now ;) > > From an UI point of view, I'd very much prefer a combo or radio buttons > instead. We do not use checkboxes this way in the LyX GUI until now, and I > think we should keep the UI consistent. > > Jürgen Simply clicking on the checkbox is much more convenient than selecting a item in a combobox. Peter
Re: :frontend::ProgressViewWidget::settingsLayout missing
Am Mittwoch, den 06.01.2010, 10:36 -0500 schrieb Manoj Rajagopalan: > > On Wednesday 06 January 2010 05:42:35 am Kornel Benko wrote: > > Am Wednesday 06 January 2010 schrieb Jean-Marc Lasgouttes: > > > "Vincent van Ravesteijn - TNW" writes: > > > > Would the attached be something ? > > > > > > Still same error here (qt 4.2.3). > > > > > > JMarc > > > > Same with qt 4-4.3.1 (OpenSuSE 10.3) > > > > Kornel > > Same with qt 4.3.4 / KUbuntu 8.04 / i686 > > -- Manoj When the designer is only PITA, then we should drop the ui file and make it by hand. Peter
Re: About the new Debug Window
Am Dienstag, den 05.01.2010, 15:12 +0100 schrieb Abdelrazak Younes: > Vincent van Ravesteijn - TNW wrote: > > > > > >> Pavel, Peter, > >> > >> Shouldn't the "All debug" and "No debug" be in radio buttons > >> instead? I guess I'd like to have 3 radio buttons: > >> > >> * All debug > >> * No debug > >> * Custom debug > >> > >> Choosing the first two would disable all checkboxes and > >> choosing the last one will enable them. > >> > > > > From the r32764 thread of yesterday: > > > > Citing myself: > > "Moreover, the any checkbox should toggle all checkboxes when clicked. It > > should either set them all checked or unset them all." > > > > Les grands esprits se rencontrent :-) ??? > > > Citing pavel: > > "Unless you want to make some connection horror there will be always > > problems how to deal with all messages and no messages checkboxes." > > > > That's why checkbox was a wrong choice for all or no messages. I've committed a patch: It's still a checkbox but with three states: it toggles between all levels enabled, all disabled, and previous selected levels. Hope it's perfect now ;) Peter
Re: r32670 - in lyx-devel/trunk/src: frontends/qt4 frontends/qt4/ui support
Pavel Sanda wrote:
> kuem...@lyx.org wrote:
>> +struct LevelButton : QRadioButton
>> +{
>> +LevelButton(const QString& name) : QRadioButton(name) {}
>> +Debug::Type level;
>> +};
>
> we will need checkboxes or buttons, since the levels can be combined.
> you can set eg files+version control debug level.
>
> i'm not sure its easy job, it would be fine to use use more horizontal space
> of the window
> for the boxes, eg. two or three columns.
feel free to visit your friend 'designer' ;)
But two columns shouldn't be too hard.
>
>> +void GuiProgressView::levelChanged(QAbstractButton* b)
>> +{
>> +LevelButton* lb = dynamic_cast(b);
>> +if (lb)
>> +lyxerr.level(lb->level);
>
> i crafted special lfun for this since i think we shouldn't set such things
> directly from ui.
but it needs a string.
>
>> @@ -19,7 +20,7 @@
>> #define LYXDEBUG_H
>>
>> #include "support/strfwd.h"
>> -
>> +#include
>
> ouch ouch ouch. we have to avoid this since debug.h is included everywhere and
> we have to keep it as as tiny as possible.
is gone now
>
> if you find time to fix those, i'll be happy. if not i fix them myself
> but it will take some time, i'm not on my box next days :)
>
> bye
> pavel
>
Re: r32670 - in lyx-devel/trunk/src: frontends/qt4 frontends/qt4/ui support
Pavel Sanda wrote:
> Pavel Sanda wrote:
>> kuem...@lyx.org wrote:
>>> +struct LevelButton : QRadioButton
>>> +{
>>> + LevelButton(const QString& name) : QRadioButton(name) {}
>>> + Debug::Type level;
>>> +};
>> we will need checkboxes or buttons, since the levels can be combined.
>> you can set eg files+version control debug level.
>
> yep and the update button can be killed, its just leftover...
> pavel
>
I've switched to check boxes and any level combination is possible now.
But the dialog still needs some cleanup.
Peter
Re: [Patch] LyXErr into progress debug pane
rgheck wrote:
> On 12/29/2009 02:22 PM, Peter Kümmel wrote:
>> After the reply to JMarc I also tought about a template solution.
>> Attached a patch, but it's tested only with msvc.
>>
>>
> Don't you only need the one specialization, if all the others are different?
>
> rh
Making the operator<< a template doesn't work here, additionally then we
would have a template in debug.h which slows down compiling a bit.
Peter
>
>> LyXErr& operator<<(LyXErr& l, void const * t)
>> -STREAM_OPERATOR(t)
>> +{ return toStream(l, t); }
>> LyXErr& operator<<(LyXErr& l, char const * t)
>> -STREAM_OPERATOR(t)
>> +{ return toStream(l, t); }
>> LyXErr& operator<<(LyXErr& l, char t)
>> -STREAM_OPERATOR(t)
>> +{ return toStream(l, t); }
>> LyXErr& operator<<(LyXErr& l, int t)
>> -STREAM_OPERATOR(t)
>> +{ return toStream(l, t); }
>> LyXErr& operator<<(LyXErr& l, unsigned int t)
>> -STREAM_OPERATOR(t)
>> +{ return toStream(l, t); }
>> LyXErr& operator<<(LyXErr& l, long t)
>> -STREAM_OPERATOR(t)
>> +{ return toStream(l, t); }
>> LyXErr& operator<<(LyXErr& l, unsigned long t)
>> -STREAM_OPERATOR(t)
>> +{ return toStream(l, t); }
>> LyXErr& operator<<(LyXErr& l, double t)
>> -STREAM_OPERATOR(t)
>> +{ return toStream(l, t); }
>> LyXErr& operator<<(LyXErr& l, string const& t)
>> -STREAM_OPERATOR(t)
>> +{ return toStream(l, t); }
>> LyXErr& operator<<(LyXErr& l, docstring const& t)
>> -STREAM_OPERATOR(to_utf8(t));
>> +{ return toStream(l, to_utf8(t)); }
>> LyXErr& operator<<(LyXErr& l, FileName const& t)
>> -STREAM_OPERATOR(t)
>> +{ return toStream(l, t); }
>> LyXErr& operator<<(LyXErr& l, ostream&(*t)(ostream&))
>> -STREAM_OPERATOR(t)
>> +{ return toStream(l, t); }
>> LyXErr& operator<<(LyXErr& l, ios_base&(*t)(ios_base&))
>> -STREAM_OPERATOR(t)
>> +{ return toStream(l, t); }
>>
>
>> Peter
>>
>
Re: [Patch] LyXErr into progress debug pane
Pavel Sanda wrote:
>> I do not really understand either why we need this STREAM_OPERATOR macro.
>
> why we need is quite clear - there is xtimes the same code and we dont want to
> copy nad paste it. i dont like the macro solution but i failed to produce
> template which would be desirable for this. either my c++ skills are lacking
> or
> it is not possible to instantiate operator templates out of class body -
> compiler takes the template without problems but but linker claims not to find
> instances needed. and yes this is the most ugly part. maybe our c++ wizard
> Andre' have an idea? :)
>
> pavel
>
After the reply to JMarc I also tought about a template solution.
Attached a patch, but it's tested only with msvc.
Peter
Index: src/support/debug.cpp
===
--- src/support/debug.cpp (Revision 32670)
+++ src/support/debug.cpp (Arbeitskopie)
@@ -192,45 +192,46 @@
// It seems not possible to instantiate operator template out of class body
-#define STREAM_OPERATOR(t) \
-{\
- if (l.enabled()){\
- l.stream() << t;\
- if (l.second_used()){\
- l.second() << t;\
- ProgressInterface::instance()->lyxerrFlush();\
- }\
- }\
- return l;\
+template
+LyXErr & toStream(LyXErr & l, T t)
+{
+ if (l.enabled()){
+ l.stream() << t;
+ if (l.second_used()){
+ l.second() << t;
+ ProgressInterface::instance()->lyxerrFlush();
+ }
+ }
+ return l;
}
LyXErr & operator<<(LyXErr & l, void const * t)
-STREAM_OPERATOR(t)
+{ return toStream(l, t); }
LyXErr & operator<<(LyXErr & l, char const * t)
-STREAM_OPERATOR(t)
+{ return toStream(l, t); }
LyXErr & operator<<(LyXErr & l, char t)
-STREAM_OPERATOR(t)
+{ return toStream(l, t); }
LyXErr & operator<<(LyXErr & l, int t)
-STREAM_OPERATOR(t)
+{ return toStream(l, t); }
LyXErr & operator<<(LyXErr & l, unsigned int t)
-STREAM_OPERATOR(t)
+{ return toStream(l, t); }
LyXErr & operator<<(LyXErr & l, long t)
-STREAM_OPERATOR(t)
+{ return toStream(l, t); }
LyXErr & operator<<(LyXErr & l, unsigned long t)
-STREAM_OPERATOR(t)
+{ return toStream(l, t); }
LyXErr & operator<<(LyXErr & l, double t)
-STREAM_OPERATOR(t)
+{ return toStream(l, t); }
LyXErr & operator<<(LyXErr & l, string const & t)
-STREAM_OPERATOR(t)
+{ return toStream(l, t); }
LyXErr & operator<<(LyXErr & l, docstring const & t)
-STREAM_OPERATOR(to_utf8(t));
+{ return toStream(l, to_utf8(t)); }
LyXErr & operator<<(LyXErr & l, FileName const & t)
-STREAM_OPERATOR(t)
+{ return toStream(l, t); }
LyXErr & operator<<(LyXErr & l, ostream &(*t)(ostream &))
-STREAM_OPERATOR(t)
+{ return toStream(l, t); }
LyXErr & operator<<(LyXErr & l, ios_base &(*t)(ios_base &))
-STREAM_OPERATOR(t)
+{ return toStream(l, t); }
// The global instance
Re: [Patch] LyXErr into progress debug pane
Am Dienstag, den 29.12.2009, 16:26 +0100 schrieb Jean-Marc Lasgouttes: > Le 28 déc. 09 à 00:06, Pavel Sanda a écrit : > > i would like to get better online gui control over lyxerr output and > > its levels > > adjusting. firstly we need to imbibe message from lyxerr into > > progress debug pane. > > > > this patch does it (plus minus some eoln stuff for gui), but i'm not > > sure this > > kind of lyxerr tweak is acceptible. JMarc? > > The changes to lyxerr are IMO ugly, but I am not competent enough to > propose something else. > Possible solutions I would try are: > * have the debug window watch the debug output > * use signal/slot ProgressInterface::instance()->lyxerrFlush(); emits a signal > * keep lyxerr where it is and subclass it with a version that handles > debug window too. > > I do not really understand either why we need this STREAM_OPERATOR > macro. There is 13 times the same code. > > JMarc
Re: [Patch] LyXErr into progress debug pane
Peter Kümmel wrote: > > Are you at the moment working on it? I've added the radio buttons. > I've committed a ui for the debug levels, I've also committed your debug patches. But we still need to fiddle a bit with the line endings. But after the fight with designer I need a break ;) Peter
Re: [Patch] LyXErr into progress debug pane
Pavel Sanda wrote:
> Peter Kümmel wrote:
>> This is a good idea. We could make the current view a tab view, or add
>> an new dialog which also provides some check boxes or radio buttons for
>> the error levels.
>
> that was my idea - either checkboxes or small buttons.
>
>> +void GuiProgress::dolyxerrFlush()
>> +{
>> + appendMessage(toqstr(lyxerr_stream_.str()));
>>
>> Call appendError or the difference between messages and errors gets
>> lost. We could als introduce somethigk like appendLyxError function.
>
> yes somthing of this sort would be needed, curently lyxerr messages are
> bit wrongly formated in window.
>
>> +void GuiProgress::lyxerrConnect()
>> +{
>> + lyxerr.setSecond(&lyxerr_stream_);
>> +}
>>
>> Why do you need this function? Couldn't setSecond be called in the ctor
>> of GuiProcess?
>
> i only want it to be initialized when once guiprogressview is showed.
> putting it into ctor of view is problem because we need lyxerr_stream_
> in guiprogress.
> pavel
>
Are at the moment working on it? I've added the radio buttons.
Peter
Re: [Patch] LyXErr into progress debug pane
Am Montag, den 28.12.2009, 00:06 +0100 schrieb Pavel Sanda:
> hi,
>
> i would like to get better online gui control over lyxerr output and its
> levels
> adjusting. firstly we need to imbibe message from lyxerr into progress debug
> pane.
>
This is a good idea. We could make the current view a tab view, or add
an new dialog which also provides some check boxes or radio buttons for
the error levels.
> this patch does it (plus minus some eoln stuff for gui), but i'm not sure this
> kind of lyxerr tweak is acceptible. JMarc?
>
> pavel
+void GuiProgress::dolyxerrFlush()
+{
+ appendMessage(toqstr(lyxerr_stream_.str()));
Call appendError or the difference between messages and errors gets
lost. We could als introduce somethigk like appendLyxError function.
+ lyxerr_stream_.str("");
+}
+void GuiProgress::lyxerrConnect()
+{
+ lyxerr.setSecond(&lyxerr_stream_);
+}
Why do you need this function? Couldn't setSecond be called in the ctor
of GuiProcess?
Peter
Re: Question about startProcess - signal problem
Am Sonntag, den 27.12.2009, 14:03 +0100 schrieb Peter Kümmel: > Definitely a bug in Qt on Linux: > bool QProcess::waitForStarted(int msecs) > calls in the unix version (qprocess_unix.cpp) of > bool QProcessPrivate::waitForStarted(int msecs) > the function > bool QProcessPrivate::_q_startupNotification() > which emits the signal. And after QProcessPrivate::waitForStarted > has returned QProcess:waitForStarted emits the signal again. http://bugreports.qt.nokia.com/browse/QTBUG-7039
Re: Question about startProcess - signal problem
Am Samstag, den 26.12.2009, 17:54 +0100 schrieb Peter Kümmel:
> > > It's a Qt bug, at least for 4.5.2. Don't know what happens with 4.6.
>
> Same with 4.6.0.
Definitely a bug in Qt on Linux:
bool QProcess::waitForStarted(int msecs)
calls in the unix version (qprocess_unix.cpp) of
bool QProcessPrivate::waitForStarted(int msecs)
This calls
bool QProcessPrivate::_q_startupNotification()
which emits the signal. And after QProcessPrivate::waitForStarted
has returned QProcess:waitForStarted emits the signal again.
This is a simple fix:
diff --git a/corelib/io/qprocess.cpp b/corelib/io/qprocess.cpp
index 7ef590e..f7d8e7b 100644
--- a/corelib/io/qprocess.cpp
+++ b/corelib/io/qprocess.cpp
@@ -1609,6 +1609,8 @@ bool QProcess::waitForStarted(int msecs)
if (d->processState == QProcess::Starting) {
if (!d->waitForStarted(msecs))
return false;
+if (d->processState == QProcess::Running)
+return true;
setProcessState(QProcess::Running);
emit started();
}
Peter
Re: Question about startProcess - signal problem
Should be much better now. Peter
Re: Question about startProcess - signal problem
Am Samstag, den 26.12.2009, 18:20 +0100 schrieb Pavel Sanda: > > > 17:11:09: Successful preview of format: ps > > > > Three times processFinished()? I've committed the some patch as for > > processStarted(). > > heh i have next strange thing. each time you interate latex compilation > the number of outputed "Successful preview of format: ps" increments by one ;) Read your mail after sending my last one. ;) > > pavel
Re: Question about startProcess - signal problem
Am Samstag, den 26.12.2009, 18:02 +0100 schrieb Peter Kümmel: > > 17:11:09: Successful preview of format: ps > > 17:11:09: Successful preview of format: ps > > 17:11:09: Successful preview of format: ps This correlates with the number of open views. There is somewhere a bug in the combination of GuiProgessView/GuiProgess/GuiView connections and message forwarding, but today I've no time to fix it. Peter
Re: Question about startProcess - signal problem
Am Samstag, den 26.12.2009, 17:13 +0100 schrieb Pavel Sanda: > > unfortunately thats not much of help for 4.5.3. > create new file type something randonly nad try to compile it for a few times: > 17:11:08: Previewing ... > 17:11:08: pplatex "newfile1.tex" only called once, so the patch works. > 17:11:08: pplatex: Process input file newfile1.dvi > 17:11:09: pplatex: Copy data to newfile1.dvi > 17:11:09: dvips -o "newfile1.ps" "newfile1.dvi" > 17:11:09: This is dvips(k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: 'his is dvips(k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' is is dvips(k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' Ts is dvips(k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' Te is dvips(k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeXis dvips(k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX s dvips(k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX o dvips(k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX oudvips(k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX outvips(k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX outpips(k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX outpups(k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX outputs(k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output (k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 2k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 20) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 200 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 20095.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 2009..97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 2009.197 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 2009.127 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 2009.12. Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 2009.12.2Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 2009.12.26opyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 2009.12.26:pyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 2009.12.26:1yright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 2009.12.26:17right 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 2009.12.26:171ight 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 2009.12.26:1711ght 2008 Radical Eye Software > (www.radicaleye.com) A bug in void SystemcallPrivate::stdOut() ? Or a completely wrong usage of QProcess. QProcess is really annoying. > 17:11:09: ' TeX output 2009.12.26:1711' -> newfile1.ps > 17:11:09: ile1.ps > 17:11:09: > 17:11:09: tware > (www.radicaleye.com) > 17:11:09: > 17:11:09: lm/lm-ec.enc> > 17:11:09: . /lm-ec.enc> > 17:11:09: . > 17:11:09: re > (www.radicaleye.com) > 17:11:09: [1 > (www.radicaleye.com) > 17:11:09: [1] > www.radicaleye.com) > 17:11:09: [1] > 17:11:09: gv "/trash/lyx_tmpdir.XM2798/lyx_tmpbuf2/newfile1.ps" > 17:11:09: Successful preview of format: ps > 17:11:09: Successful preview of format: ps > 17:11:09: Successful preview of format: ps Three times processFinished()? I've committed the some patch as for processStarted(). Peter
Re: Question about startProcess - signal problem
Am Samstag, den 26.12.2009, 17:13 +0100 schrieb Pavel Sanda: > Peter Kümmel wrote: > > Am Freitag, den 25.12.2009, 18:38 +0100 schrieb Pavel Sanda: > > > hi, > > > > > > some messages in progress debug window are doubled now. > > > > > > we use signal/slot mechanism for seeing process started > > > connect(proc_, SIGNAL(started()), this, SLOT(processStarted())); > > > > > > for reason i dont understand we reach into the processStarted() slot > > > twice for a single call. this seems to happen inside call > > > return proc_->waitForStarted(timeout); (Systemcall.cpp:298) > > > > > > is this expected or a bug? > > > > It's a Qt bug, at least for 4.5.2. Don't know what happens with 4.6. Same with 4.6.0. > > unfortunately thats not much of help for 4.5.3. > create new file type something randonly nad try to compile it for a few times: > 17:11:08: Previewing ... > 17:11:08: pplatex "newfile1.tex" > 17:11:08: pplatex: Process input file newfile1.dvi > 17:11:09: pplatex: Copy data to newfile1.dvi > 17:11:09: dvips -o "newfile1.ps" "newfile1.dvi" > 17:11:09: This is dvips(k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: 'his is dvips(k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' is is dvips(k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' Ts is dvips(k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' Te is dvips(k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeXis dvips(k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX s dvips(k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX o dvips(k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX oudvips(k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX outvips(k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX outpips(k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX outpups(k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX outputs(k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output (k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 2k) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 20) 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 200 5.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 20095.97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 2009..97 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 2009.197 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 2009.127 Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 2009.12. Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 2009.12.2Copyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 2009.12.26opyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 2009.12.26:pyright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 2009.12.26:1yright 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 2009.12.26:17right 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 2009.12.26:171ight 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 2009.12.26:1711ght 2008 Radical Eye Software > (www.radicaleye.com) > 17:11:09: ' TeX output 2009.12.26:1711' -> newfile1.ps > 17:11:09: ile1.ps > 17:11:09: > 17:11:09: tware > (www.radicaleye.com) > 17:11:09: > 17:11:09: lm/lm-ec.enc> > 17:11:09: . /lm-ec.enc> > 17:11:09: . > 17:11:09: re > (www.radicaleye.com) > 17:11:09: [1 > (www.radicaleye.com) > 17:11:09: [1] > www.radicaleye.com) > 17:11:09: [1] > 17:11:09: gv "/trash/lyx_tmpdir.XM2798/lyx_tmpbuf2/newfile1.ps" > 17:11:09: Successful preview of format: ps > 17:11:09: Successful preview of format: ps > 17:11:09: Successful preview of format: ps > > pavel
Re: Question about startProcess - signal problem
Am Freitag, den 25.12.2009, 18:38 +0100 schrieb Pavel Sanda:
> hi,
>
> some messages in progress debug window are doubled now.
>
> we use signal/slot mechanism for seeing process started
> connect(proc_, SIGNAL(started()), this, SLOT(processStarted()));
>
> for reason i dont understand we reach into the processStarted() slot
> twice for a single call. this seems to happen inside call
> return proc_->waitForStarted(timeout); (Systemcall.cpp:298)
>
> is this expected or a bug?
It's a Qt bug, at least for 4.5.2. Don't know what happens with 4.6.
Index: src/support/Systemcall.cpp
===
--- src/support/Systemcall.cpp (Revision 32641)
+++ src/support/Systemcall.cpp (Arbeitskopie)
@@ -406,8 +406,10 @@
void SystemcallPrivate::processStarted()
{
- state = Running;
- ProgressInterface::instance()->processStarted(cmd_);
+ if (state != Running) {
+state = Running;
+ProgressInterface::instance()->processStarted(cmd_);
+}
}
Peter
Re: Question about startProcess - signal problem
Pavel Sanda wrote: > hi, > > some messages in progress debug window are doubled now. > > we use signal/slot mechanism for seeing process started > connect(proc_, SIGNAL(started()), this, SLOT(processStarted())); > > for reason i dont understand we reach into the processStarted() slot > twice for a single call. this seems to happen inside call > return proc_->waitForStarted(timeout); (Systemcall.cpp:298) > > is this expected or a bug? > pavel > The Qt doc says: "This signal is emitted by QProcess when the process has started, and state() returns Running." Does this mean the signal is emitted twice? What does the Qt documentation exegesis say? Signal is called twice, Amen? Peter
Re: r32604 - in lyx-devel/trunk: lib/ui src/frontends/qt4 src/support
Pavel Sanda wrote: > Pavel Sanda wrote: >> Pavel Sanda wrote: >>> Vincent van Ravesteijn wrote: > no luck. it might be older problem, i'll have a look. > pavel > Is it the same problem as this: http://thread.gmane.org/gmane.editors.lyx.devel/123158 >>> i have suspiction that movement of VC_ lfuns into GuiView is responsible >>> here. >>> >>> all messages are cleared out at the end of lyxfunc processing now and >>> since there is no dispatchResult for GuiView, we cant use setMessage >>> for resulting string. >>> >>> just bisecting to see the problematic commit. >> i was right http://www.lyx.org/trac/changeset/31376 > > sorry cut and paste error http://www.lyx.org/trac/changeset/32604 I couldn't find the cut and paste error in my commit > >> pavel >
Re: r32604 - in lyx-devel/trunk: lib/ui src/frontends/qt4 src/support
Pavel Sanda wrote: > Peter, it looks statusbar is somewhat damaged now. > previously some LFUNs displayed results through statusbar > which is no more true. i only see timestamp(dow we need it?) +name of > completed > LFUN. for example when we have checked from svn tree, one could see on status > bar > revision number of checkout, change of lock etc - now there is useless > time: vc-check-in > > could you have a look? I've disabled the processFinished message, hope it helps. Peter
Re: Invitation to google wave
> To make things more clear, my main interest with Wave in connection with > LyX is that I think there are interesting things in Wave as a concept > which we eventually could incorporate into LyX. (I don't advocate us using > Wave at this time for developer communication, maybe I never will) > > Now, in order for other LyX developers to have the opportunity to see > what's possible in Wave, you need an account, for which you need an > invite. Much more interesting is the open source solution EtherPad http://code.google.com/p/etherpad/ http://etherpad.com/ep/blog/posts/etherpad-open-source-release Peter
Progress dialog on Mac
>> Could someone with a Mac check if attached patch is a good solution on a Mac?
>
> Functionally, this works well: LaTeX, etc. runs in the background,
> with the widget being updated with process messages. I'd prefer to
> have the process messages cleared for subsequent attempts to typeset
> rather than simply appended to the end of the previous list, however;
> otherwise the list gets long and it's hard to tell when one run ended
> and the next began. Another solution might be to indicate in the list
> the time that typesetting began, something like this:
>
> 9:58 p.m.
> Process started: pdflatex "filename"
> Process finished: pdflatex "filename"
>
> 10:00 p.m.
> Process started: ...
>
> In terms of Mac aesthetics, drawers seem to be going out of style,
> replaced instead by floating windows. (Perhaps other Mac users would
> care to chime in here.) I think that's what makes most sense not only
> here but also in other cases. In particular:
>
> 1. Document > Outline should not be a drawer but floating window.
>
> 2. Anything that uses a vertical dock should be a floating widget.
> This includes such things as the spellcheck widget and the advanced
> find and replace widget, but *not* the view source widget.
>
> (It probably would make sense to allow floating widgets to dock if
> someone wanted to do that, but the default on Mac should be to have
> them float.)
>
> That goes beyond what you're asking here. Should I file a bug report
> on these other cases so as not to hijack this thread?
>
> Bennett
>
Here a new thread for the Mac ui discussion, someone should care about
Dialog * createGuiProgressView(GuiView & guiview)
{
#ifdef Q_WS_MACX
return new GuiProgressView(guiview, Qt::RightDockWidgetArea,
Qt::Drawer);
#else
return new GuiProgressView(guiview, Qt::BottomDockWidgetArea);
#endif
}
in GuiProgressView.cpp.
Peter
Re: Background LaTeX, Etc
Kornel Benko wrote: > /usr/src/lyx/lyx-devel/src/frontends/qt4/GuiView.cpp:278: error: > ‘preview_watcher_’ was not Could you try it again? Peter
Re: Background LaTeX, Etc
Pavel Sanda wrote: > Peter Kümmel wrote: >> But I've removed the dialog, because ATM we don't have to >> show anything interesting. Latex is running in batch mode. > > i hoped we could duplicate the terminal output into this dock widget > and i even intended to add more capabilities for debug output > fine tuning. Cool, I've re-added the dialog. It's now in GuiProgressView. > could we reeanble that dock? i'm bit confused what should > be reverted since the critical commit mixes more actions together ;) > > pavel >
Re: Background LaTeX, Etc
Kornel Benko wrote: > Am Monday 21 December 2009 schrieb BH: >> On Mon, Dec 21, 2009 at 10:08 AM, Vincent van Ravesteijn - TNW >> wrote: >> Right now I can't compile: >> > Can you compile now ? Not quite. (I should have run make -k before.) >>> And now ? >> Perfect -- thanks! >> >> BH >> > > Not here, > I get now: > > This is Qt4-4.3 on openSuSE 10.3 > > Kornel Should work now with all Qt versions. Peter
Re: Background LaTeX, Etc
> > And then continuous update on each buffer change.
> >
>
> I tried that on linux and it is bearable but crashy... This is on a 2
> year old laptop running Ubuntu 9.10.
Isn't that bad on Linux with attached patch. We have to drop updates
when the update is still busy.
>
> On Windows, forget about it, Miktex is just too slow, incredibly slow
> compared to Linux.
Index: src/frontends/qt4/GuiView.cpp
===
--- src/frontends/qt4/GuiView.cpp (Revision 32608)
+++ src/frontends/qt4/GuiView.cpp (Arbeitskopie)
@@ -273,7 +273,7 @@
void setPreviewFuture(QFuture const & f)
{
if (preview_watcher_.isRunning())
- preview_watcher_.waitForFinished();
+return;
preview_watcher_.setFuture(f);
connect(&preview_watcher_, SIGNAL(finished()), gv_,
SLOT(threadFinished()));
Index: src/frontends/qt4/GuiWorkArea.cpp
===
--- src/frontends/qt4/GuiWorkArea.cpp (Revision 32608)
+++ src/frontends/qt4/GuiWorkArea.cpp (Arbeitskopie)
@@ -456,6 +456,7 @@
// the cursor gets restarted in GuiView::restartCursor()
stopBlinkingCursor();
guiApp->processKeySym(key, mod);
+lyx_view_->dispatch(FuncRequest(LFUN_BUFFER_UPDATE, "dvi"));
}
Re: Background LaTeX, Etc
Am Montag, den 21.12.2009, 14:54 +0100 schrieb Abdelrazak Younes: > Excellent. Now we can also move LFUN_BUFFER_EXPORT to thread. We just > need a new argument to exportAndDestroy() AFAIR. I mean... if you want > to do some more work on this ;-) And then continuous update on each buffer change. Peter
Re: Background LaTeX, Etc
Am Montag, den 21.12.2009, 14:54 +0100 schrieb Abdelrazak Younes:
> Peter Kümmel wrote:
> > Abdelrazak Younes wrote:
> >
> >> 2) Use the same signal/slot mechanism for Buffer::message().
> >>
> >
> > Done,
> > http://www.lyx.org/trac/changeset/32606/lyx-devel/trunk
> >
>
> Excellent. Now we can also move LFUN_BUFFER_EXPORT to thread. We just
> need a new argument to exportAndDestroy() AFAIR. I mean... if you want
> to do some more work on this ;-)
>
> Abdel.
Why do we need a new argument? Wouldn't attached patch be ok?
Peter
Index: src/frontends/qt4/GuiView.cpp
===
--- src/frontends/qt4/GuiView.cpp (Revision 32608)
+++ src/frontends/qt4/GuiView.cpp (Arbeitskopie)
@@ -2691,10 +2691,20 @@
lyx::dispatch(FuncRequest(LFUN_DIALOG_SHOW, "sendto"));
break;
}
+#if EXPORT_in_THREAD && (QT_VERSION >= 0x040400)
+ ProgressInterface::instance()->clearMessages();
+ QString time = QTime::currentTime().toString(Qt::SystemLocaleShortDate);
+ ProgressInterface::instance()->appendMessage(time + ": Exporting ...\n");
+ QFuture f = QtConcurrent::run(exportAndDestroy,
+doc_buffer->clone(), argument);
+ d.setPreviewFuture(f);
+#else
+
if (doc_buffer->doExport(argument, false)) {
message(bformat(_("Error exporting to format: %1$s."),
cmd.argument()));
}
+#endif
break;
}
Re: #32597 breaks trunk
Am Montag, den 21.12.2009, 10:30 -0500 schrieb Ben M.: > On Mon, Dec 21, 2009 at 9:30 AM, Vincent van Ravesteijn - TNW > wrote: > > Try adding "#include " to GuiProgress.cpp. > > > > PS. You can keep this on the list. > > > > (Peter, you compile with a single merged header file ?) > > > > Vincent > > Thanks! I also had to add QTime to GuiView.cpp. Now it compiles. > > -Ben Sorry for the trouble, I had pre-compiled headers enabled. Peter
Re: Background LaTeX, Etc
Abdelrazak Younes wrote: > 2) Use the same signal/slot mechanism for Buffer::message(). Done, http://www.lyx.org/trac/changeset/32606/lyx-devel/trunk Peter
Re: Background LaTeX, Etc
Abdelrazak Younes wrote: > On 20/12/2009 17:34, Peter Kümmel wrote: >> Abdelrazak Younes wrote: >> >>> 1) Replace all call to Alert::warning() related to some Buffer action >>> with a new Buffer::warning() method that will use the GuiDelegate to >>> send the warning to the GUI even when we are in another thread. This is >>> because new widget cannot be created from another thread so we must >>> implement a signal from the thread that will ask the main thread to >>> launch the dialog. >>> >> Shouldn't we simply move all Alert::warning() calls into the Gui thread? >> > > That would be nice yes. > >> (Then we need some signal/sot stuff in GuiAlert.cpp) >> > > That would be a solution. > The void functions of Alert:: are now forwarded to GuiProgress. Peter
Re: Background LaTeX, Etc
BH wrote: > On Sun, Dec 20, 2009 at 11:23 AM, Peter Kümmel wrote: >> Peter Kümmel wrote: >>> Pavel Sanda wrote: >>>> Peter Kümmel wrote: >>>>> If it's really needed I could move it to trunk, would not be very >>>>> complicated. >>>> yes it would be nice to have it. i even imagine line of checkboxes on the >>>> top >>>> each for one debug level to toggle - that would be quite useful for >>>> debugging >>>> purposes. also user reports could be more useful... >>> I've added a simple version which only shows started and finished command >>> and >>> errors in a dock widget. But it could be extended. >>> >> Could someone with a Mac check if attached patch is a good solution on a Mac? > > Functionally, this works well: LaTeX, etc. runs in the background, > with the widget being updated with process messages. I'd prefer to > have the process messages cleared for subsequent attempts to typeset > rather than simply appended to the end of the previous list, however; > otherwise the list gets long and it's hard to tell when one run ended > and the next began. Another solution might be to indicate in the list > the time that typesetting began, something like this: > > 9:58 p.m. > Process started: pdflatex "filename" > Process finished: pdflatex "filename" Nice idea with the time, added it. Statusbar is now updated ehith the progress information. But I've removed the dialog, because ATM we don't have to show anything interesting. Latex is running in batch mode. Peter > > 10:00 p.m. > Process started: ... > > In terms of Mac aesthetics, drawers seem to be going out of style, > replaced instead by floating windows. (Perhaps other Mac users would > care to chime in here.) I think that's what makes most sense not only > here but also in other cases. In particular: > > 1. Document > Outline should not be a drawer but floating window. > > 2. Anything that uses a vertical dock should be a floating widget. > This includes such things as the spellcheck widget and the advanced > find and replace widget, but *not* the view source widget. > > (It probably would make sense to allow floating widgets to dock if > someone wanted to do that, but the default on Mac should be to have > them float.) > > That goes beyond what you're asking here. Should I file a bug report > on these other cases so as not to hijack this thread? > > Bennett >
Re: #32597 breaks trunk
Vincent van Ravesteijn - TNW wrote: >> The latest trunk doesn't link for me with scons/win32. >> It does work if I roll back. > > So, you'll have to fix scons ;-).. Just like Peter did in r32600 for > autotools. Fixed it. I thought scons parses the .am files. Peter
Re: Background LaTeX, Etc
Abdelrazak Younes wrote: > 1) Replace all call to Alert::warning() related to some Buffer action > with a new Buffer::warning() method that will use the GuiDelegate to > send the warning to the GUI even when we are in another thread. This is > because new widget cannot be created from another thread so we must > implement a signal from the thread that will ask the main thread to > launch the dialog. Shouldn't we simply move all Alert::warning() calls into the Gui thread? (Then we need some signal/sot stuff in GuiAlert.cpp) Peter
Re: Background LaTeX, Etc
Peter Kümmel wrote: > Pavel Sanda wrote: >> Peter Kümmel wrote: >>> If it's really needed I could move it to trunk, would not be very >>> complicated. >> yes it would be nice to have it. i even imagine line of checkboxes on the top >> each for one debug level to toggle - that would be quite useful for debugging >> purposes. also user reports could be more useful... > > I've added a simple version which only shows started and finished command and > errors in a dock widget. But it could be extended. > Could someone with a Mac check if attached patch is a good solution on a Mac? Peter Index: src/frontends/qt4/GuiProgress.cpp === --- src/frontends/qt4/GuiProgress.cpp (Revision 32603) +++ src/frontends/qt4/GuiProgress.cpp (Arbeitskopie) @@ -97,7 +97,7 @@ GuiView & guiview = static_cast(lv); #ifdef Q_WS_MACX // TODO where to show up on the Mac? - //return new GuiProgress(guiview, Qt::RightDockWidgetArea, Qt::Drawer); + return new GuiProgress(guiview, Qt::RightDockWidgetArea, Qt::Drawer); #else return new GuiProgress(guiview, Qt::BottomDockWidgetArea); #endif
Re: Link Error
rgheck wrote: > CXXLD lyx > frontends/qt4/liblyxqt4.a(GuiView.o): In function > `lyx::frontend::GuiView::build(std::basic_string std::char_traits, std::allocator > const&)': > /cvs/lyx-devel/trunk/src/frontends/qt4/GuiView.cpp:3478: undefined > reference to `lyx::frontend::createGuiProgress(lyx::frontend::GuiView&)' > collect2: ld returned 1 exit status > make[4]: *** [lyx] Error 1 > > This was on a clean check-out. Sorry, forgot to update the Makefiles. Peter
Re: Background LaTeX, Etc
Pavel Sanda wrote: > Peter Kümmel wrote: >> If it's really needed I could move it to trunk, would not be very >> complicated. > > yes it would be nice to have it. i even imagine line of checkboxes on the top > each for one debug level to toggle - that would be quite useful for debugging > purposes. also user reports could be more useful... I've added a simple version which only shows started and finished command and errors in a dock widget. But it could be extended. Peter
svn:eol-style native
Is there any reason why no svn:eol-style native property is set an the src files? Peter
Re: Background LaTeX, Etc
Abdelrazak Younes wrote: > On 19/12/2009 12:43, Peter Kümmel wrote: >>> I implemented that approach now in trunk. But by cloning the Buffer as >>> this was the cleanest approach and less intrusive approach. It works >>> well except for the lack of feedback on the background processing. >>> >>> Abdel. >>> >> Great, if it works we could remove >> QCoreApplication::processEvents(QEventLoop::AllEvents); >> in Systemcall.cpp which is responsible for several crashes. >> > > How is this related? We don't need the explizit processing of GUI events any more because the buffer processing does not block the GUI any more. > >> But atm nothing happens when I press the "View" button in the toolbar. >> > > This toolbar item seems broken currently but I don't think this is > related to my commit. Menu -> view or update (pdflatex or dvi) works > fine here (as well as Ctrl+D or T) > >> Any places where I could help? >> > > Yes, if you have time there are two things: > > 1) Replace all call to Alert::warning() related to some Buffer action > with a new Buffer::warning() method that will use the GuiDelegate to > send the warning to the GUI even when we are in another thread. This is > because new widget cannot be created from another thread so we must > implement a signal from the thread that will ask the main thread to > launch the dialog. > > 2) Use the same signal/slot mechanism for Buffer::message(). > > Abdel. >
Re: Background LaTeX, Etc
Vincent van Ravesteijn wrote: >> When I change the function parameter for format from docstring to >> std:string I get linker errors with mavc, because of missing >> previewAndDestroy and exportAndDestroy, stange. >> Thereforethe from_utf8 function. >> >> Peter >> >> > I can just change the format type to string without any problems (msvc > as well). > It was bformat, it doesn't take a std::string. Peter
Re: Background LaTeX, Etc
Abdelrazak Younes wrote: >> No not here. Would this patch be OK? >> > > Yes, my bad. Any ideas why static docstring exportAndDestroy(Buffer * buffer, std::string const & format) does not work? Qt without stl support? Peter
Re: r32579 - in lyx-devel/trunk: lib src/support
Enrico Forestieri wrote: > On Sat, Dec 19, 2009 at 07:20:57PM +0100, Peter Kümmel wrote: > >> OK, htlatex needs the ! as argument and ! has here no bash functionality. >> Under Windows unquoted should work, because no bash there. >> But what should we do on Linux? As the bug report says single quotes does >> not work. >> One way remains: no quotes but escaped !: symbol/\!. Will this work? >> Not an Linux atm. > > If you are referring to bug 6266, then my last commit should have solved it. > Moreover, now it would be better to also revert your changes to configure.py > (i.e., put back the single quotes). In this way it will be working whether or > not QProcess is disabled. > > Note that the bug was reported for 2.0 and essentially was due to the fact > that the simple parser didn't account for the single-quotes when using > QProcess (the bug doesn't exist when QProcess is disabled, as the shell > strips the quotes). Now it does, so the changes to configure.py can (and > should) be reverted. > As I already said, you are the master of quotes! ;) I'll revert configure.py. Peter
Re: Background LaTeX, Etc
Vincent van Ravesteijn wrote: >> But preview is still broken under Windows. >> >> Peter >> > > I didn't fix it ? > > Vincent > No not here. Would this patch be OK? Index: src/frontends/qt4/GuiView.cpp === --- src/frontends/qt4/GuiView.cpp (Revision 32590) +++ src/frontends/qt4/GuiView.cpp (Arbeitskopie) @@ -2687,7 +2687,7 @@ format = doc_buffer->getDefaultOutputFormat(); #if EXPORT_in_THREAD && (QT_VERSION >= 0x040400) QFuture f = QtConcurrent::run(exportAndDestroy, - doc_buffer->clone(), cmd.argument()); + doc_buffer->clone(), from_utf8(format)); d.setPreviewFuture(f); #else doc_buffer->doExport(format, true); @@ -2702,7 +2702,7 @@ format = doc_buffer->getDefaultOutputFormat(); #if EXPORT_in_THREAD && (QT_VERSION >= 0x040400) QFuture f = QtConcurrent::run(previewAndDestroy, - doc_buffer->clone(), cmd.argument()); + doc_buffer->clone(), from_utf8(format)); d.setPreviewFuture(f); #else doc_buffer->preview(format); @@ -2718,7 +2718,7 @@ format = master->getDefaultOutputFormat(); #if EXPORT_in_THREAD && (QT_VERSION >= 0x040400) QFuture f = QtConcurrent::run(exportAndDestroy, - master->clone(), cmd.argument()); + master->clone(), from_utf8(format)); d.setPreviewFuture(f); #else master->doExport(format, true); @@ -2732,7 +2732,7 @@ format = master->getDefaultOutputFormat(); #if EXPORT_in_THREAD && (QT_VERSION >= 0x040400) QFuture f = QtConcurrent::run(previewAndDestroy, - master->clone(), cmd.argument()); + master->clone(), from_utf8(format)); d.setPreviewFuture(f); #else master->preview(format); When I change the function parameter for format from docstring to std:string I get linker errors with mavc, because of missing previewAndDestroy and exportAndDestroy, stange. Thereforethe from_utf8 function. Peter
Re: Background LaTeX, Etc
Pavel Sanda wrote: > Abdelrazak Younes wrote: >> 2) Use the same signal/slot mechanism for Buffer::message(). > > btw in the old process branch there was implemnted new output window for > console > messages. how hard it would be to make it work the current trunk? it would be > good > to have this for latex output in background and for version control output as > well... > > pavel > If it's really needed I could move it to trunk, would not be very complicated. But preview is still broken under Windows. Peter
Re: r32579 - in lyx-devel/trunk: lib src/support
Enrico Forestieri wrote: > On Sat, Dec 19, 2009 at 12:35:17PM +0100, Peter Kümmel wrote: >> Am Samstag, den 19.12.2009, 12:22 +0100 schrieb Peter Kümmel: >>> The doc to htlatex says: >>> "In some platforms the double quotes should be replaced with single >>> right-quotes, and in some cases they might be omitted." >>> http://www.cse.ohio-state.edu/~gurari/TeX4ht/ >>> >>> This helps not much. > > On the contrary, it says all. You simply have to know the quoting rules on > a given platform. > >> Double quotes on Linux does not work: >> lyx_tmpbuf0$ htlatex "UserGuide.tex" "html,word" "symbol/!" "-cvalidae" >> bash: !": event not found > > This is to be expected, as ! doesn't lose its special meaning inside double > quotes. Either you enclose it in single-quotes or escape it by a backslash. > >> This is OK >> lyx_tmpbuf0$ htlatex "UserGuide.tex" "html,word" symbol/! "-cvalidae" > > This only works because the ! is immediately followed by a space, which is > one of the characters (the others are: tab, newline, carriage return, and = ) > that inhibit history expansion, so ! behaves as a normal character even if > it is unquoted. > >> also >> lyx_tmpbuf0$ htlatex "UserGuide.tex" "html,word" 'symbol/!' "-cvalidae" > > Here, the single-quotes preserve the literal meaning of the ! character. > >> lyx_tmpbuf0$ htlatex "UserGuide.tex" html,word symbol/! -cvalidae > > Good again, as ! is followed by a space. > >> lyx_tmpbuf0$ htlatex "UserGuide.tex" html,word "symbol/\!" -cvalidae > > Here the ! is escaped so it loses its special meaning. However, this line > is not good, as the escaped ! is inside double-quotes, and in this case the > backslash will not be removed, i.e., htlatex will literally see symbol/\! > which is not what is wanted. > >> Some htlatex experts here? > > This has nothing to do with htlatex. Use "man bash" and search for HISTORY > EXPANSION for the gory details about the meaning of ! for the shell. OK, htlatex needs the ! as argument and ! has here no bash functionality. Under Windows unquoted should work, because no bash there. But what should we do on Linux? As the bug report says single quotes does not work. One way remains: no quotes but escaped !: symbol/\!. Will this work? Not an Linux atm. Peter
Re: Background LaTeX, Etc
> I implemented that approach now in trunk. But by cloning the Buffer as > this was the cleanest approach and less intrusive approach. It works > well except for the lack of feedback on the background processing. > > Abdel. Great, if it works we could remove QCoreApplication::processEvents(QEventLoop::AllEvents); in Systemcall.cpp which is responsible for several crashes. But atm nothing happens when I press the "View" button in the toolbar. Any places where I could help? Peter
Re: r32579 - in lyx-devel/trunk: lib src/support
Am Samstag, den 19.12.2009, 12:22 +0100 schrieb Peter Kümmel: > Am Freitag, den 18.12.2009, 23:33 +0100 schrieb Enrico Forestieri: > > > configure.py should still be OK, because the quotes > > > the are du to spaces in filenames only, hope I'm not > > > totally wrong here, too. > > > > I don't use htlatex, so I really don't know. However, if the single quotes > > were meant for quoting the arguments and are not part of the htlatex syntax, > > then the configure.py patch should be correct (in this case, maybe you could > > have replaced the single quotes with double ones). I see that one of the > > arguments contain a '!' character, so when using a shell that should be > > escaped. Of course, this is not (should not be) the case with QProcess. > > If the single quotes were meant to quote the arguments, I wonder whether > > the htlatex converter ever worked on Windows, whose shell doesn't strip away > > single quotes. > > > > The doc to htlatex says: > "In some platforms the double quotes should be replaced with single > right-quotes, and in some cases they might be omitted." > http://www.cse.ohio-state.edu/~gurari/TeX4ht/ > > This helps not much. Double quotes on Linux does not work: lyx_tmpbuf0$ htlatex "UserGuide.tex" "html,word" "symbol/!" "-cvalidae" bash: !": event not found This is OK lyx_tmpbuf0$ htlatex "UserGuide.tex" "html,word" symbol/! "-cvalidae" also lyx_tmpbuf0$ htlatex "UserGuide.tex" "html,word" 'symbol/!' "-cvalidae" lyx_tmpbuf0$ htlatex "UserGuide.tex" html,word symbol/! -cvalidae lyx_tmpbuf0$ htlatex "UserGuide.tex" html,word "symbol/\!" -cvalidae Some htlatex experts here? Peter
Re: r32579 - in lyx-devel/trunk: lib src/support
Am Samstag, den 19.12.2009, 09:25 +0100 schrieb Jürgen Spitzmüller: > Enrico Forestieri wrote: > > > Thanks, I didn't thought someone likes single quotes > > > in his filenames. I've reverted the Systemcall.cpp patch. > > > > Thanks. I have also committed a patch such that file names can now also > > contain the double quote character. Note that on *nix you can use any > > character (except '/') in a file name. > > BTW there's also an old bug report about single quotes in path names: > http://www.lyx.org/trac/ticket/4063 > > Would be great if this could be fixed. I could not reproduce this bug with trunk: - USB-stick name : Stick'N'Go - copied BRANCH_1_4_X/lib to stick - opened UserGuide.lyx from stick - PDF is generated without errors Is this the right way to reproduce? If yes then, it is not a bug for trunk any more. Peter
Re: r32579 - in lyx-devel/trunk: lib src/support
Am Freitag, den 18.12.2009, 23:33 +0100 schrieb Enrico Forestieri: > > configure.py should still be OK, because the quotes > > the are du to spaces in filenames only, hope I'm not > > totally wrong here, too. > > I don't use htlatex, so I really don't know. However, if the single quotes > were meant for quoting the arguments and are not part of the htlatex syntax, > then the configure.py patch should be correct (in this case, maybe you could > have replaced the single quotes with double ones). I see that one of the > arguments contain a '!' character, so when using a shell that should be > escaped. Of course, this is not (should not be) the case with QProcess. > If the single quotes were meant to quote the arguments, I wonder whether > the htlatex converter ever worked on Windows, whose shell doesn't strip away > single quotes. > The doc to htlatex says: "In some platforms the double quotes should be replaced with single right-quotes, and in some cases they might be omitted." http://www.cse.ohio-state.edu/~gurari/TeX4ht/ This helps not much. Peter
Re: r32579 - in lyx-devel/trunk: lib src/support
Enrico Forestieri wrote:
> On Fri, Dec 18, 2009 at 01:20:23PM +0100, kuem...@lyx.org wrote:
>
>> Author: kuemmel
>> Date: Fri Dec 18 13:20:22 2009
>> New Revision: 32579
>> URL: http://www.lyx.org/trac/changeset/32579
>>
>> Log:
>> Ticket 6266 Quoting Problem with QProcess: don't think we need any quotes
>> (at least on Linux)
>
> This commit is totally wrong. First, you do not distinguish between single-
> and double-quotes quoting, such that "this is quoted and a ' is in here" is
> not correctly parsed. Second, you cannot arbitrarily change characters
> because, if you have a filename containing a single quote, the converter will
> fail. Try to insert an xfig file named foo'09.fig and see what happens when
> you try to view dvi, postscript, or pdf. This was working before this commit.
> Please revert.
>
Thanks, I didn't thought someone likes single quotes
in his filenames. I've reverted the Systemcall.cpp patch.
configure.py should still be OK, because the quotes
the are du to spaces in filenames only, hope I'm not
totally wrong here, too.
Peter
>
>> Modified:
>>lyx-devel/trunk/lib/configure.py
>>lyx-devel/trunk/src/support/Systemcall.cpp
>>
>> Modified: lyx-devel/trunk/lib/configure.py
>> ==
>> --- lyx-devel/trunk/lib/configure.py Fri Dec 18 13:08:32 2009(r32578)
>> +++ lyx-devel/trunk/lib/configure.py Fri Dec 18 13:20:22 2009(r32579)
>> @@ -647,9 +647,9 @@
>> addToRC(r'''\copierhtml "python -tt
>> $$s/scripts/ext_copy.py $$i $$o"''')
>>
>> # On SuSE the scripts have a .sh suffix, and on debian they are in
>> /usr/share/tex4ht/
>> -path, htmlconv = checkProg('a LaTeX -> MS Word converter', ["htlatex
>> $$i 'html,word' 'symbol/!' '-cvalidate'", \
>> -"htlatex.sh $$i 'html,word' 'symbol/!' '-cvalidate'", \
>> -"/usr/share/tex4ht/htlatex $$i 'html,word' 'symbol/!'
>> '-cvalidate'"],
>> +path, htmlconv = checkProg('a LaTeX -> MS Word converter', ["htlatex
>> $$i html,word symbol/! -cvalidate", \
>> +"htlatex.sh $$i html,word symbol/! -cvalidate", \
>> +"/usr/share/tex4ht/htlatex $$i html,word symbol/! -cvalidate"],
>> rc_entry = [ r'\converter latex wordhtml "%%"
>> "needaux"' ])
>> if htmlconv.find('htlatex') >= 0:
>>addToRC(r'''\copierwordhtml "python -tt
>> $$s/scripts/ext_copy.py -e html,png,css $$i $$o"''')
>> @@ -667,7 +667,7 @@
>> # Both SuSE and debian have oolatex
>> checkProg('a LaTeX -> Open Document converter', [
>> 'oolatex $$i', 'mk4ht oolatex $$i', 'oolatex.sh $$i',
>> '/usr/share/tex4ht/oolatex $$i',
>> -'htlatex $$i \'xhtml,ooffice\' \'ooffice/! -cmozhtf\' \'-coo\'
>> \'-cvalidate\''],
>> +'htlatex $$i xhtml,ooffice ooffice/! -cmozhtf -coo -cvalidate'],
>> rc_entry = [ r'\converter latex odt"%%"
>> "needaux"' ])
>> # On windows it is called latex2rt.exe
>> checkProg('a LaTeX -> RTF converter', ['latex2rtf -p -S -o $$o $$i',
>> 'latex2rt -p -S -o $$o $$i'],
>>
>> Modified: lyx-devel/trunk/src/support/Systemcall.cpp
>> ==
>> --- lyx-devel/trunk/src/support/Systemcall.cpp Fri Dec 18 13:08:32
>> 2009(r32578)
>> +++ lyx-devel/trunk/src/support/Systemcall.cpp Fri Dec 18 13:20:22
>> 2009(r32579)
>> @@ -82,7 +82,7 @@
>>
>> for (size_t i = 0; i < cmd.length(); ++i) {
>> char c = cmd[i];
>> -if (c == '"' && !escaped)
>> +if ((c == '"' || c == '\'') && !escaped)
>> inquote = !inquote;
>> else if (c == '\\' && !escaped)
>> escaped = !escaped;
>> @@ -103,7 +103,12 @@
>> int Systemcall::startscript(Starttype how, string const & what, bool
>> process_events)
>> {
>> string outfile;
>> -QString cmd = toqstr(parsecmd(what, outfile));
>> +QString cmd = toqstr(parsecmd(what, outfile));
>> +if (cmd.contains("'")) {
>> +LYXERR0("Systemcall: '" << cmd << "' contains single quotes ',
>> please check configuration, ' will be replaced by \"");
>> +cmd = cmd.replace("'","\"");
>> +}
>> +
>> SystemcallPrivate d(outfile);
>>
>>
>>
>
Re: Exporting in a separate thread
Am Montag, den 07.12.2009, 09:34 +0100 schrieb Abdelrazak Younes: > > No problem, disabling the changes is simple. How does instant preview > > work? What means 'instant' in this context? Does it use threads > > > > No, instant preview was already using detached process. The only thing > special here is that a full screen redraw is scheduled each time a new > preview is ready. Ben's question is why we don't use the same mechanism > for LateX too and it is a good question. Basically because LateX > compilation is deeply integrated within LyX (we need to keep track of 5 > or 6 compilation) it is difficult to detach it. One "easy solution would > be to clone the to-be-compiled Buffer and starts the LateX export and > the compilation from a new thread. This would be the best approach. And having such a solution would make it possible to TeXing on each buffer change without triggering it manually (What should I do with all the cores in my processsor?) Peter
Re: Exporting in a separate thread
Am Sonntag, den 06.12.2009, 18:53 -0500 schrieb Ben M.: > On Sun, Dec 6, 2009 at 4:43 PM, Peter Kümmel wrote: > > Before the patch LyX was single-threaded; means, processing an > > user-event, like pressing a button, had to wait until all previewing > > is done. > > I never had to wait for "Instant Preview." Is that not classified as > a "user-event"? > > >> I have no idea what I'm looking for. The buffer is > >> still frozen while rendering a preview. Do you expect this??? > > > > No, I wonder why. Is it really frozen, or is the cursor only invisible. > > Could you scroll the view? > > Occasionally I can move the cursor around, but the vast majority of > the time, the buffer freezes. I cannot use the scrollbars. (I > suspect that for the few times when I could move the cursor, I had not > modified the buffer, so LyX was not actually rendering anything new.) Seems LyX is busy within it's own thread, then processing events while a process is running doesn't help much. The initial idea of the patch was to show only progress information, so you can see what LyX is doing and is not blocked only. > > > But there are still a moments when LyX is frozen. Only when external > > tools like latex or bibtex are busy the GUI could react on user input. > > When LyX generates internally the TeX code it is still blocked, because > > this is not done in a separate thread. > > Internal generation of TeX code is very quick for me. What slows > things down the most is when LaTeX reruns several times to generate my > references. > > Please excuse my ignorance, but why can't we simply perform exports > the same way that we currently generate instant previews? No problem, disabling the changes is simple. How does instant preview work? What means 'instant' in this context? Does it use threads Peter
Re: Exporting in a separate thread
Am Sonntag, den 06.12.2009, 12:38 -0500 schrieb Ben M.: > > Just work as usual with the current version and see if something > > strange happens. The are may possibilities of bugs, e.g. what happens > > when you click several times on the preview button? > > Could you please summarize the expected behavior of your > modifications? Before the patch LyX was single-threaded; means, processing an user-event, like pressing a button, had to wait until all previewing is done. Now processing of user-events is also done while previewing (or while other external tools are busy), e.g. you could close the document while previewing. And ATM LyX has no code to forbid (synchronize) such scenarios. And nobody knows what bugs this change has introduced. Welcome to the multi-threaded/process hell ;) > I have no idea what I'm looking for. The buffer is > still frozen while rendering a preview. Do you expect this??? No, I wonder why. Is it really frozen, or is the cursor only invisible. Could you scroll the view? But there are still a moments when LyX is frozen. Only when external tools like latex or bibtex are busy the GUI could react on user input. When LyX generates internally the TeX code it is still blocked, because this is not done in a separate thread. > > When I click the preview button several times, the console displays: > ../../../src/support/Systemcall.cpp(112): error An unknown error occured. > > I can trigger a segfault by quitting LyX while the preview is generating. Very good, you've found the first bad consequence! > > -Ben
Re: Exporting in a separate thread
Ben M. wrote: > On Sat, Dec 5, 2009 at 4:31 PM, Andre Poenitz wrote: >> I'd use valgrind --tool=callgrind and kcachegrind for visualization. > > Currently I'm equipped for compiling LyX only under cygwin and win32. > A brief Google search indicates that valgrind doesn't work on these > platforms. :( > > My linux server is running an ancient version of ubuntu (6.06). Due > to old versions of automake, the latest LyX it compiles is 1.6.2. I > need to upgrade, but I dread reconfiguring all my services. You could try it with cmake which is maybe simpler to install. Peter
Re: Exporting in a separate thread
Ben M. wrote: > > Back to the original topic... Peter, is there anything I can do to > test out your patches? > Just work as usual with the current version and see if something strange happens. The are may possibilities of bugs, e.g. what happens when you click several times on the preview button? Thanks, Peter
Re: r32323 - lyx-devel/trunk/src/support
Pavel Sanda wrote: > Peter Kümmel wrote: >> I've commited attached patch. >> Then you could disable event processing for the svn call. > > great. > > one more glitch. when i edit lyx file and just push ctrl+shift+t to render > postcript window in background, for first 2-3s cursor disappears, while cursor > moving&editing still works - only not displayed in workarea. you can see this > clearly in environment box - as the cursor moves, the environment changes too. > but mouse hour-cursor and no keyboard cursor wrongly indicates that editation > is not possible. I assume the mouse icon and cursor are switched to 'busy' before the script is called. Now this isn't correct any more, and we have to remove the relevant switches. Peter
Re: r32323 - lyx-devel/trunk/src/support
Pavel Sanda wrote: > Peter Kuemmel wrote: If it breaks anything or someone really dislikes it we could disable it >>> again. >>> >>> whats the difference from users pov? >> The GUI should not be blocked any more while processing a huge document. > > so the old famous http://www.lyx.org/trac/ticket/412 in fact. > i tested it here and seemes to work so far. Cool, the bug was 8 years old. > consider to write record into wiki newinlyx20. Do I need a special account? > > pavel >
Re: r32323 - lyx-devel/trunk/src/support
Pavel Sanda wrote:
> Peter Kuemmel wrote:
I've enabled processing user input, see patch.
If it breaks anything or someone really dislikes it we could disable it
>>> again.
>>>
>>> whats the difference from users pov?
>> The GUI should not be blocked any more while processing a huge document.
>
> would it be possible to selectively switch it off for certain usage?
> i just get problem in the following scenario:
>
> triggering svn update. i dont wait until update happens and start typing.
> because
> this happens in the critical time after check for dirty buffer was done and
> update
> has not happened yet, lyx runs into clash, and lyx runs into emergency cycle.
>
> i would need that nobody touches anything while doing svn stuff.
>
> pavel
>
I've commited attached patch.
Then you could disable event processing for the svn call.
Peter
Index: src/support/Systemcall.cpp
===
--- src/support/Systemcall.cpp (Revision 32329)
+++ src/support/Systemcall.cpp (Arbeitskopie)
@@ -99,13 +99,12 @@
-int Systemcall::startscript(Starttype how, string const & what)
+int Systemcall::startscript(Starttype how, string const & what, bool
process_events)
{
string outfile;
QString cmd = toqstr(parsecmd(what, outfile));
SystemcallPrivate d(outfile);
- bool process_events = true;
d.startProcess(cmd);
if (!d.waitWhile(SystemcallPrivate::Starting, process_events, 3000)) {
Index: src/support/Systemcall.h
===
--- src/support/Systemcall.h(Revision 32328)
+++ src/support/Systemcall.h(Arbeitskopie)
@@ -42,7 +42,7 @@
* The string "what" contains a commandline with arguments separated
* by spaces.
*/
- int startscript(Starttype how, std::string const & what);
+ int startscript(Starttype how, std::string const & what, bool
process_events = true);
};
} // namespace support
Re: r32323 - lyx-devel/trunk/src/support
Abdelrazak Younes wrote:
> Hum, I did that in Systemcall::startscript() and didn't notice a
> difference... maybe I am missing something?
I've enabled processing user input, see patch.
If it breaks anything or someone really dislikes it we could disable it again.
The event processing only happens when a process is called. The GUI still hangs
when LyX by itself is busy, eg. while loading a big document.
Peter
Index: src/support/Systemcall.cpp
===
--- src/support/Systemcall.cpp (Revision 32328)
+++ src/support/Systemcall.cpp (Arbeitskopie)
@@ -105,7 +105,7 @@
QString cmd = toqstr(parsecmd(what, outfile));
SystemcallPrivate d(outfile);
- bool process_events = false;
+ bool process_events = true;
d.startProcess(cmd);
if (!d.waitWhile(SystemcallPrivate::Starting, process_events, 3000)) {
Re: r32327 - lyx-devel/trunk/src/support
Pavel Sanda wrote: > sa...@lyx.org wrote: >> Author: sanda >> Date: Fri Dec 4 12:06:29 2009 >> New Revision: 32327 >> URL: http://www.lyx.org/trac/changeset/32327 >> >> Log: >> gcc complains because of inicialization order > > there are also unused vars warn, bu these are because this code is not still > finished i guess. Yes, but I will switch to GCC soon to remove such warnings. Peter
Re: r32323 - lyx-devel/trunk/src/support
Abdelrazak Younes wrote: > No, I mean that by default this inherits QThread privately... It's a struct, not a class ;) Peter
Re: r32323 - lyx-devel/trunk/src/support
Abdelrazak Younes wrote: > kuem...@lyx.org wrote: >> Author: kuemmel >> Date: Fri Dec 4 10:51:13 2009 >> New Revision: 32323 >> URL: http://www.lyx.org/trac/changeset/32323 >> >> Log: >> Move some code from the process branch into trunk. >> Don't incorporated any progess stuff. >> Behavior when starting a process is UNTOUCHED, but could simply changed by >> setting progessEvents to true. > > Hum, I did that in Systemcall::startscript() and didn't notice a > difference... maybe I am missing something? Havn't tries it here, atm I only cleanup to simplify the code. > >> Modified: lyx-devel/trunk/src/support/Systemcall.cpp >> + >> +struct Sleep : QThread > > public QThread ? needed to free the protected sleep function. > >> +bool SystemcallPrivate::waitWhile(State waitwhile, bool processEvents, int >> timeout) > > + bool waitWhile(State, bool processEvents, int timeout = -1); > > process_events Ahh! > > Abdel. >
Re: Boost And Compilation
Jean-Marc Lasgouttes wrote: >> Better is to switch to tr1, and as fallback to use an external boost >> tr1 implementation. > > The part that is problematic for stdlib-debug, I think, is boost::regex. > Does tr1 contain something like that? Yes, but it is not 100% source compatible (at least with msvc). > > We could also: > > - have external-boost be the default for releases > - have internal-boost be the default for devel versions (or at lease > make sure it is compilable). > > I speak for autotools of course, but I think we should make the same > choices for the different architectures. > > How is boost used for windows BTW? For releases I assume internal, because there is no system-boost. > > JMarc >
Re: Boost And Compilation
Abdelrazak Younes wrote: > > An easier long-term fix (for branch) would be to make > --with-external-boost the default. > Better is to switch to tr1, and as fallback to use an external boost tr1 implementation. Peter
Re: Boost And Compilation
>> I think we should do that. Peter, could you perform the boost upgrade >> for branch? Done, branch now compiles with gcc 4.4.1. Peter
Re: r31103 - lyx-devel/trunk/development/cmake/src/support
Kornel Benko wrote:
> Am Montag 17 August 2009 schrieb kuem...@lyx.org:
>> if(Boost_FOUND)
>>target_link_libraries(support ${Boost_LIBRARIES})
>> else()
>> - target_link_libraries(support boost_signals)
>> + target_link_libraries(support boost_signals boost_regex)
>> endif()
>
Found the error ;)
>
> We could have defined boost_libraries in the main CmakeLists.txt, and
> then use later in deeper cmake-files.
>
Feel free to cleanup the files.
Peter
>
> Something like
> if(Boost_FOUND)
> set(Our_Boost_Libs ${Boost_LIBRARIES})
> else()
> set(Our_Boost_Libs boost_signals boost_regex)
> endif()
>
>
> Kornel
>
>
Re: boost 1.39 update
Andre Poenitz wrote: >> What were the reasons at the last meeting not to drop boost? > > Using tr1 turned out not to be a drop-in replacement. > I've updated to boost 1.39 and tested on Linux and Windows. I get a strange lyxclient linker error when building with cmake, Kornel do you have an idea what's going wrong? Peter
