Re: linking error due to missing boost::assertion_failed_msg()
Sorry, mistyped the last “f”: it should have been 01ee3bf1e5, the master branch on 5 sept. > On 8 Sep 2019, at 09:34, Stephan Witt wrote: > > Am 07.09.2019 um 10:14 schrieb pdv : >> >> LyX fails to build on macos (Mojave, CMake, XCode) with the latest commit >> (01ee3bf1f5) with message: >> >> Undefined symbols for architecture x86_64: >> "boost::assertion_failed_msg(char const*, char const*, char const*, char >> const*, long)", referenced from: >> boost::array::operator[](unsigned long) in >> ConverterCache.o >> boost::array::operator[](unsigned long) in >> libfrontend_qt.a(GuiApplication.o) >> boost::array::operator[](unsigned long) in >> libsupport.a(FileName.o) >> boost::array::operator[](unsigned long) in >> libfrontend_qt.a(GuiClipboard.o) >> >> From the boost docs >> (https://www.boost.org/doc/libs/1_68_0/libs/assert/doc/html/assert.html) >> it's clear that boost::assertion_failed_msg() must be defined, ... >> >> If the macro BOOST_ENABLE_ASSERT_HANDLER is defined when >> is included, BOOST_ASSERT_MSG(expr,msg) expands to >> >> (BOOST_LIKELY(!!(expr))? ((void)0): ::boost::assertion_failed_msg(#expr, >> msg, BOOST_CURRENT_FUNCTION, __FILE__, __LINE__)) >> This is true regardless of whether NDEBUG is defined. >> >> boost::assertion_failed_msg is declared in as >> >> namespace boost >> { >> void assertion_failed_msg(char const * expr, char const * msg, >> char const * function, char const * file, long line); >> } >> but it is never defined. The user is expected to supply an appropriate >> definition. >> >> ... which is not the case now, and BOOST_ASSERT_MSG is defined in >> boost::array.hpp. >> >> I've defined the additional function assertion_failed_msg()in boost.cpp >> (patch attached) and this resolves the problem. >> >> Two more remarks: >> >> 1) I don't understand why this problem surfaces now and not earlier; >> >> 2) There are additional definitions of assertion_failed() in >> client/boost.cpp and in tex2lyx/boost.cpp; > > I cannot find the commit 01ee3bf1f5. Is it a local one in your git checkout? > > I don’t have this problem with neither with automake nor with cmake. > > Stephan Patrick De Visschere 051/46 70 25 Pensionaatstraat 25 8755 Ruiselede smime.p7s Description: S/MIME cryptographic signature
Re: linking error due to missing boost::assertion_failed_msg()
Yes, I have a few different settings (but I didn’t change them recently as far as I know) and I’m using (gui) CMake 3.15.1 and XCode = Version 10.3 (10G8) LYX_CPACK = ON : Use the CPack management (Implies LYX_INSTALL option) LYX_LOCALVERSIONING = OFF : Add version info to created package name (only used if LYX_CPACK option set) LYX_INSTALL = ON : Build install projects/rules (implies a bunch of other options) LYX_NLS = ON : Enable Native Language Support (NLS) LYX_REQUIRE_SPELLCHECK = OFF : Abort if no spellchecker available LYX_ASPELL = ON : Require aspell LYX_ENCHANT = OFF : Require Enchant LYX_HUNSPELL = ON : Require Hunspell LYX_RELEASE = OFF : Build release version, build debug when disabled LYX_DEBUG = OFF : Enforce debug build LYX_NO_OPTIMIZE = ON : Don't use any optimization/debug flags LYX_PACKAGE_SUFFIX = ON : Use version suffix for packaging LYX_SUFFIX_VALUE = : Use this string as suffix LYX_PCH = OFF : Use precompiled headers LYX_MERGE_FILES = OFF : Merge source files into one compilation unit LYX_MERGE_REBUILD = OFF : Rebuild generated files from merged files build LYX_QUIET = ON : Don't generate verbose makefiles LYX_INSTALL_PREFIX = OFF : Install path for LyX LYX_BUNDLE = ON : Build bundle (experimental) LYX_ENABLE_URLTESTS = OFF : Enable for URL tests LYX_ENABLE_EXPORT_TESTS = OFF : Enable for export tests LYX_ENABLE_KEYTESTS = OFF : Enable for keytests LYX_ASAN = OFF : Use address sanitizer LYX_USE_FILEDIALOG = QT : Use native or QT file dialog (QT NATIVE) LYX_USE_QT = QT5 : Use Qt version as frontend (AUTO QT4 QT5) LYX_DISABLE_CALLSTACK_PRINTING = OFF : do not print a callstack when crashing LYX_EXTERNAL_Z = ON : OFF := Build 3rdparty lib zlib LYX_EXTERNAL_ICONV = ON : OFF := Build 3rdparty lib iconvlib LYX_EXTERNAL_HUNSPELL = OFF : OFF := Build 3rdparty lib hunspelllib LYX_EXTERNAL_MYTHES = OFF : OFF := Build 3rdparty lib mytheslib (AUTO OFF ON) LYX_DMG = ON : Build as Mac bundle, needed for .dmg (experimental) LYX_COCOA = ON : Use Cocoa on Mac In the source files (ConverterCache.cpp, Application.cpp, FileName.cpp and GuiClipboard.cpp) I don’t see macro’s which could optionally include the relevant code which is probably in the boost::crc module. I suppose boost::crc uses boost::array where the BOOST_ASSERT_MSG macro is activated, triggering the error. LyX includes a 3thparty boost-version (1.68), but I don’t find any references to it in my XCode project and I think I’m actually using my macports boost (which is 1.71). This might explain it: I’ve upgraded my macports boost and this breaks my lyx-build. > On 8 Sep 2019, at 10:14, Stephan Witt wrote: > > Am 08.09.2019 um 10:02 schrieb Patrick De Visschere : >> >> Sorry, mistyped the last “f”: it should have been 01ee3bf1e5, the master >> branch on 5 sept. > > I see. Yes, this is HEAD for me too. This is what works for me. > > Perhaps you have different cmake flags? > > I have: > -- LYX_CPACK = OFF : Use the CPack management > (Implies LYX_INSTALL option) > -- LYX_LOCALVERSIONING= ON: Add version info to created > package name (only used if LYX_CPACK option set) > -- LYX_INSTALL= OFF : Build install projects/rules > (implies a bunch of other options) > -- LYX_NLS= ON: Enable Native Language > Support (NLS) > -- LYX_REQUIRE_SPELLCHECK = OFF : Abort if no spellchecker > available > -- LYX_ASPELL = ON: Require aspell > -- LYX_ENCHANT= OFF : Require Enchant > -- LYX_HUNSPELL = ON: Require Hunspell > -- LYX_RELEASE= OFF : Build release version, build > debug when disabled > -- LYX_DEBUG = ON: Enforce debug build > -- LYX_NO_OPTIMIZE= OFF : Don't use any > optimization/debug flags > -- LYX_PACKAGE_SUFFIX = OFF : Use version suffix for > packaging > -- LYX_SUFFIX_VALUE = : Use this string as suffix > -- LYX_PCH= OFF : Use precompiled headers > -- LYX_MERGE_FILES= OFF : Merge source files into one > compilation unit > -- LYX_MERGE_REBUILD = OFF : Rebuild generated files from > merged files build > -- LYX_QUIET = OFF : Don't generate verbose > makefiles > -- LYX_INSTALL_PREFIX = OFF : Install path for LyX > -- LYX_BUNDLE = OFF : Build bundle (experimental) > -- LYX_ENABLE_URLTESTS= OFF : Enable for URL tests > -- LYX_ENABLE_EXPORT_TESTS= ON: Enable for export tests > -- LYX_ENABLE_KEYTESTS= OFF : Enable for keytests > -- LYX_ASAN
Re: linking error due to missing boost::assertion_failed_msg()
> On 8 Sep 2019, at 21:03, Stephan Witt wrote: > > Am 08.09.2019 um 20:47 schrieb pdv : >> >> On 08/09/2019 17:47, Kornel Benko wrote: >>> Am Sonntag, 8. September 2019, 14:14:15 CEST schrieb Patrick De Visschere: >>>> In the source files (ConverterCache.cpp, Application.cpp, FileName.cpp and >>>> GuiClipboard.cpp) I don’t see macro’s which could optionally include the >>>> relevant code which is probably in the boost::crc module. I suppose >>>> boost::crc uses boost::array where the BOOST_ASSERT_MSG macro is >>>> activated, triggering the error. >>>> >>>> LyX includes a 3thparty boost-version (1.68), but I don’t find any >>>> references to it in my XCode project and I think I’m actually using my >>>> macports boost (which is 1.71). >>>> This might explain it: I’ve upgraded my macports boost and this breaks my >>>> lyx-build. >>>> >>>> >>> There isn't any, if you don't use GCC. See CMakeLists.txt:162 >>> Kornel >> >> XCode uses clang and I believe that indeed the internal (3thparty) boost is >> used. But this contains only the regex (and signals) source code, besides >> (all) the headers. The code involved #includes and I suppose >> this code is found in the system (macports) boost. > > I have it in lyx/3rdparty/boost/boost/crc.hpp … > > Stephan Me too. But XCode picks up the one in macports. And there is no source code (crc.cpp) or no lib to link with. Patrick smime.p7s Description: S/MIME cryptographic signature
Re: linking error due to missing boost::assertion_failed_msg()
> On 9 Sep 2019, at 00:41, Stephan Witt wrote: > > Am 08.09.2019 um 22:44 schrieb Patrick De Visschere : >> >> >> >>> On 8 Sep 2019, at 21:03, Stephan Witt wrote: >>> >>> Am 08.09.2019 um 20:47 schrieb pdv : >>>> >>>> On 08/09/2019 17:47, Kornel Benko wrote: >>>>> Am Sonntag, 8. September 2019, 14:14:15 CEST schrieb Patrick De Visschere: >>>>>> In the source files (ConverterCache.cpp, Application.cpp, FileName.cpp >>>>>> and GuiClipboard.cpp) I don’t see macro’s which could optionally include >>>>>> the relevant code which is probably in the boost::crc module. I suppose >>>>>> boost::crc uses boost::array where the BOOST_ASSERT_MSG macro is >>>>>> activated, triggering the error. >>>>>> >>>>>> LyX includes a 3thparty boost-version (1.68), but I don’t find any >>>>>> references to it in my XCode project and I think I’m actually using my >>>>>> macports boost (which is 1.71). >>>>>> This might explain it: I’ve upgraded my macports boost and this breaks >>>>>> my lyx-build. >>>>>> >>>>>> >>>>> There isn't any, if you don't use GCC. See CMakeLists.txt:162 >>>>> Kornel >>>> >>>> XCode uses clang and I believe that indeed the internal (3thparty) boost >>>> is used. But this contains only the regex (and signals) source code, >>>> besides (all) the headers. The code involved #includes and >>>> I suppose this code is found in the system (macports) boost. >>> >>> I have it in lyx/3rdparty/boost/boost/crc.hpp … >>> >>> Stephan >> >> Me too. But XCode picks up the one in macports. >> >> And there is no source code (crc.cpp) or no lib to link with. > > I’m using a build script for cmake Xcode project generation. It contains: > > XCODE_SDK_PATH=${SDKROOT:-$(xcrun --show-sdk-path)} > echo Using SDK ${XCODE_SDK_PATH} > cmake … \ > -DCMAKE_SYSTEM_PREFIX_PATH="/usr;${XCODE_SDK_PATH}/usr“ > … > > Does it do the trick for you? > > Stephan No :( I’ve noticed that the XCode compile command contains the "-I/opt/local/include" directive; because the “Header Search Paths” is set that way in the project; This is inserted by cmake because I use macports aspell and magic. Patrick smime.p7s Description: S/MIME cryptographic signature
Re: LinkBack support (on MacOS)
> On 12 Sep 2019, at 18:23, Stephan Witt wrote: > > Am 08.09.2019 um 10:57 schrieb Stephan Witt : >> >> Am 25.09.2018 um 17:21 schrieb Stephan Witt : >>> >>> Am 25.09.2018 um 17:10 schrieb Jürgen Spitzmüller : Am Freitag, den 21.09.2018, 15:55 +0200 schrieb pdv: > I came across a deprecated call in the LinkBack code, and discovered > that LinkBack acctually doesn't work (anymore). > Apparently nobody uses this? Apparently. I only found this 8 year old bug related to LinkBack: https://www.lyx.org/trac/ticket/6961 > When the pasteboard contains linkback-data lyx saves the pdf-data + > linkback-data in a file with the .linkback extension and adds the > size > of the pdf-data as a uint32. > > When reading/rewriting back the size it's converted with > NSSwapBigLongToHost() and NSSwapHostLongToBig() calls. > > I suppose that the "Long" refers to 8 bytes. > > Replacing the calls by the similar "Int" calls solves the problem. > > LinkBack then works with LateXiT and with Omnigraffle. > > Enclosed is a patch for this and for replacing the deprecated call. Alas, I know nothing of this. Stephan? >>> >>> I’ll see if I can find the time. >> >> I’ve applied the patch and have no problem. I didn’t do the real test with >> linkback-data. >> I don’t have Omnigraffle an my system. >> >> The change from NSSwapBigLongToHost to NSSwapBigIntToHost is 100% correct. >> I’ll commit to master. Thank you Patrick for fixing this bug. > > I’ve commit it to master. > > Patrick, can we close the ticket in LyX’s bug tracker? > > Riki, I think we should back port the change to stable. Ok? > > Stephan I’ve checked linkback support with latexit and it works now, so you can close it. Patrick smime.p7s Description: S/MIME cryptographic signature
Re: Blanket permission
Kornel, I hereby grant permission to use my work for LyX under the license GPL version 2 or later. Patrick De Visschere smime.p7s Description: S/MIME cryptographic signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Citation with multiple keys is always labeled as broken
Since commit 4ddc9e… (master, 14 march 2020) citations with multiple keys are always labeled as broken, because the key list is handled as a single key. Included is a possible fix. Patrick citationspatch.diff Description: Binary data smime.p7s Description: S/MIME cryptographic signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX-Workarea: Background not shown correctly
> On 12 Oct 2017, at 21:30, Jean-Marc Lasgouttes wrote: > > Le 08/10/2017 à 18:57, pdv a écrit : >> The new code contains twice a viewport()->update() without specification of >> a rectangle. Since > Qt normally erases the widget's area before the >> paintEvent() call >> I guess that the whole viewport is erased. Subsequently only part of it is >> redrawn except for the case FullScreenUpdate and in that case there is no >> problem. > > Actually, we use > viewport()->setAttribute(Qt::WA_OpaquePaintEvent); > to ask Qt not to overwrite it. It seems to work on Linux. I compared the old and the new code and noticed that in the old code update(x, y, w, h) was always used with coordinates. This explanation seemed to make some sense since often a single line remains indeed visible (see tests below). And when I force a FullScreenUpdate in BufferView::draw then the problem goes away. But I see your point; When I remove the line setting WA_OpaquePaintEvent the problem remains but (most of) the view turns white instead of black; When I set WA_NoSystemBackground instead the problem remains the same. When I insert viewport()->update(0,0,500,500) then everything outside this square remains untouched but the problem persists within that square. It seems that update(area) restricts updating to the selected area, but apparently (at least on macos) one is then obliged to redraw that area completely. The Qt-docs read as follows: "Qt::WA_OpaquePaintEventIndicates that the widget paints all its pixels when it receives a paint event. Thus, it is not required for operations like updating, resizing, scrolling and focus changes to erase the widget before generating paint events. …." I understand this as: since the widget will repaint all its pixels, there is no need (for Qt) to erase the widget. Another fragment, dealing with an example, reads: "The right widget has the Qt::WA_OpaquePaintEvent widget attribute set. This indicates that the widget will paint over its entire area with opaque colors. The widget's area will initially be uninitialized, represented in the diagram with a red diagonal grid pattern that shines through the overpainted area. The Qt::WA_OpaquePaintArea attribute is useful for widgets that need to paint their own specialized contents quickly and do not need a default filled background." Apparently “uninitialized” means “black". I have no idea why this turns out correctly under linux. > > Please feel free to look at the code and docs (QWidget and > QAbstractScrollArea) and tell us what I may have missed. I just saw that we > should override viewportEvent() instead of event(), but I am not sure that it > would make a difference. > > Can you compile master? Do you see the issue? Yes and yes; Here are some observations (I used the Help/Introduction for testing): - Clicking anywhere in the window (or when scrolling) restores the view. - Inserting a CR anywhere restores the view. - Selecting anything by double clicking turns the screen black, except for some insets (like LYX, a footnote, Table of Contents) which remain visible. - Hovering with the mouse over a footnote or Table of Contents restores the view. - When moving the cursor up/down with the up/down keys usually only one line is visible (in addition to the elements mentioned higher) but it’s the line above/below the one containing the cursor. - This is also true when starting from a normal view. Moving the cursor up/down leaves the line visible where the cursor was positioned. However when a word is marked by the spellchecker then one must move the cursor an additional line before the view goes black (one can thus move the cursor within 3 lines without going black). - When moving the cursor horizontally with the arrow keys; the screen goes black except for the current line (and the insets). - Moving the cursor horizontally in a word marked by the spellchecker causes no problem. The view goes black only when entering an adjacent word. - Sometimes the view is completely blacked, also the special insets. E.g. when bringing the window to the foreground. Replacing GuiWorkArea::event() by viewportEvent() does not make a difference. If you have a suggestion for a specific test, let me know. > > JMarc smime.p7s Description: S/MIME cryptographic signature
Re: LyX-Workarea: Background not shown correctly
I’ve done some more debugging and I believe I’ve found the Qt code that turns the background black or white. Om macos (and probably also on windows) Qt uses a QBackingStore for painting. I couldn’t find a QPlatformBackingStore for linux so I assume the implementation is different on linux, which would explain the different behaviour. When issuing an viewport()->update() the region (the complete viewport if no smaller area is specified) is marked as dirty and at paint time is then repainted, via QWidgetBackingStore::doSync(). In QRasterBackingStore::beginPaint() the region is initially filled with a color Qt::transparent which has alpha=r=g=b=0 which will leave the screen black if not overwritten. When WA_OpaquePaintEvent is not set this is followed by a paintBackground() call which fills the region with the autoFillBrush-color which has all ones. This will leave the screen white if not overwritten. Depending on the update_strategy_ only a part of the screen is overwritten by lyx, leaving the rest black or white. I assume that in the tests I’ve described previously all actions restoring the normal view somehow trigger a FullScreenUpdate. pdv > On 12 Oct 2017, at 21:30, Jean-Marc Lasgouttes wrote: > > Le 08/10/2017 à 18:57, pdv a écrit : >> The new code contains twice a viewport()->update() without specification of >> a rectangle. Since > Qt normally erases the widget's area before the >> paintEvent() call >> I guess that the whole viewport is erased. Subsequently only part of it is >> redrawn except for the case FullScreenUpdate and in that case there is no >> problem. > > Actually, we use > viewport()->setAttribute(Qt::WA_OpaquePaintEvent); > to ask Qt not to overwrite it. It seems to work on Linux. > > Please feel free to look at the code and docs (QWidget and > QAbstractScrollArea) and tell us what I may have missed. I just saw that we > should override viewportEvent() instead of event(), but I am not sure that it > would make a difference. > > Can you compile master? Do you see the issue? > > JMarc smime.p7s Description: S/MIME cryptographic signature
Re: LyX-Workarea: Background not shown correctly
> On 16 Oct 2017, at 11:41, Jean-Marc Lasgouttes wrote: > > Le 13/10/2017 à 11:00, Patrick De Visschere a écrit : >> But I see your point; >> When I remove the line setting WA_OpaquePaintEvent the problem remains but >> (most of) the view turns white instead of black; >> When I set WA_NoSystemBackground instead the problem remains the same. >> When I insert viewport()->update(0,0,500,500) then everything outside this >> square remains untouched but the problem persists within that square. > > Did you try setting both WA_OpaquePaintEvent and WA_NoSystemBackground? It doesn’t make a difference. > > Does it make a difference to set them on GuiWorkarea too (additionally to the > viewport)? No. I didn’t try all combinations but adding WA_OpaquePaintEvent and then also WA_NoSystemBackground does not make a difference. pdv > > JMarc smime.p7s Description: S/MIME cryptographic signature
Re: LyX-Workarea: Background not shown correctly
This works as far as I can see. > On 19 Oct 2017, at 17:34, Jean-Marc Lasgouttes wrote: > > Le 16/10/2017 à 14:48, Patrick De Visschere a écrit : >> I’ve defined a watchpoint on what I believe is the backingstore image and >> this is the complete call stack: > > This callstack is very interesting. It tells us that syncBackingStore is > invoked from QWidget::event for the event UpdateRequest (14). In turn at (16) > we have an occasion of cathcing this event and ask for a full redraw. > > Could you try the following pair of patches? The first one is the one I am > working on in another thread (but which is not ready yet) and the second is > the one of interest here (but it depends of the first one). > > JMarc > <0001-Allow-multiple-calls-to-processUpdateFlags-before-re.patch><0001-Tentative-patch-fix-black-screen-on-Mac.patch> smime.p7s Description: S/MIME cryptographic signature
Re: LyX-Workarea: Background not shown correctly
Jean-Marc, This works because every update is turned into a FullScreenUpdate. Right? Isn’t this a waste of work? Do you consider this as a permanent solution? I’ve tried to solve the problem by using: viewport()->update(0,y,w,h) and thus specifying the proper coordinates. If I pass the coordinates of the paragraph, I notice that “SingleParUpdate" actually means “SingleRowUpdate". Since only the current paragraph is painted black now, except for the current row. There is also still a problem when making a selection and when moving the cursor around. Therefore I should pass the coordinates of the current row instead, to begin with. The selection/cursor problems might be more difficult to solve. What’s your opinion on this? pdv > On 19 Oct 2017, at 23:24, Jean-Marc Lasgouttes wrote: > > Le 19 octobre 2017 22:34:07 GMT+02:00, Patrick De Visschere > a écrit : >> This works as far as I can see. > > This is very very good news. I'll commit that as soon as the rest is in a > good enough shape, since the two are related. Thanks a lot for the detective > work. > > JMarc smime.p7s Description: S/MIME cryptographic signature
Re: LyX-Workarea: Background not shown correctly
> On 22 Oct 2017, at 23:11, Jean-Marc Lasgouttes wrote: > > Le 21 octobre 2017 14:56:36 GMT+02:00, Patrick De Visschere > a écrit : >> Jean-Marc, >> >> This works because every update is turned into a FullScreenUpdate. >> Right? > > If I understand correctly, it turns every update related to an UpdateRequest > event (something internal to qt) into a full screen update (in the LyX > sense). But I think that these updates (those which create the black screen) > are not the norm. > You can check that by adding some debug information along with the new code > in my patch to see how often it triggers. With the patch in place, SingleParUpdate in bufferView::draw is never reached. > > It would be interesting to set a break on QWindow::requestUpdate and see > whether to is something we do that triggers this effect. I did and it’s never triggered. >> Isn’t this a waste of work? >> >> Do you consider this as a permanent solution? > > Yes maybe, along with other improvement on our draw code. But I might not > understand exactly what is happening. > >> I’ve tried to solve the problem by using: viewport()->update(0,y,w,h) >> and thus specifying the proper coordinates. > > Which one? The following gives me the correct coordinates for a simple paragraph (for tables using top_pit looks better). void BufferView::rectToUpdate(int *y, int *w, int *h) { if(d->update_strategy_ == SingleParUpdate) { Text & buftext = buffer_.text(); pit_type const bottom_pit = d->cursor_.bottom().pit(); TextMetrics & tm = textMetrics(&buftext); *h = tm.parMetrics(bottom_pit).height(); *y = tm.parMetrics(bottom_pit).position() - tm.parMetrics(bottom_pit).ascent(); } else { *y = 0; *h = height_; } *w = width_; } > >> If I pass the coordinates of the paragraph, I notice that >> “SingleParUpdate" actually means “SingleRowUpdate". Since only the >> current paragraph is painted black now, except for the current row. > > Interesting. Does this mean that we could somehow disable completely these > black screen paintings ? Actually I need the coordinates of the current Row instead of those of the Paragraph, but sofar I couldn’t find this information. I’m afraid that the currrent Row of a paragraph is not cached somewhere. And this does not work yet when making a selection or moving the cursor around. It will only work if for every update we can pass via viewport()->update(x, y, w,h) the exact area to be painted later. If it’s too large it will be partially black and if too small updates will be missed. > > The whole situation is not clear to me as you can see. I’m still having problems with the basics. I thought there existed a document describing the basics of textMetrics, paragraphMetrics … . I found something on the wiki but not so much. > > JMarc > smime.p7s Description: S/MIME cryptographic signature
Re: LyX-Workarea: Background not shown correctly
> On 25 Oct 2017, at 16:28, Jean-Marc Lasgouttes wrote: > > Le 25/10/2017 à 16:15, Patrick De Visschere a écrit : >>> So finally you mean that an UpdateRequest is really fired for each update >>> event (which makes sense :), right? >> The patch turns every update into a FullScreenUpdate and SingleParUpdate is >> then obsolete. >> Every call to viewport()->update() leads to a QEvent::updateRequest I guess. > > Yes, I meant without the patch that does a full repaint on each full paint > event. > >> btw this was about the function requestUpdate(), not the QEvent. > > I suspect they are the same, but the Qt source is really too big for me. I > tried to understand what happens, but it is hard to grasp. > >> Yes I found the crcCheck on a row. >> But when forcing a FullScreenUpdate this code becomes useless, since with >> pi.full_repaint=true every line is redrawn. > > Of course, if we force, we force. > >>> I do not like much the idea of just restricting the update area, since it >>> seems very fragile. But we can return to it if needed. There are ways to >>> get all the coordinates that we need. >> I agree. The dimensions passed via update(x,y,w,h) and the actual area >> painted must match exactly. I cannot judge the penalty of the screen >> redraws. I doesn’t seem to hurt very much. >> Nevertheless I have now something which works mostly. There are still >> problems when dragging a selection but I believe these can be solved by fine >> tuning. The other problem is that when opening a document the screen stil >> turns black. > > And the other problem is that we do a lot of useless painting (that is > ignored by the clipping but probably still costs us). > >>> There is a point that I would like to clear though: is the screen turned to >>> black at each event (insertion of a character...), or only when certain >>> things happen, like the example of doing a PDF preview like Stephan >>> described at the beginning of this thread? >> When typing, the whole screen stays black, except for the current line, >> which looks normal. You don’t have to do anything special to get this. >> That’s what I expect: when typing a single character in a row, only that row >> will be repainted but the update() triggers a full screen erase. >> With a big document it’s sufficient to scroll a little bit to trigger a >> FullScreenUpdate. So maybe when not typing and moving the mouse around it >> might not always be obvious. >> And within a table there is no problem, meaning that the cells do not turn >> black. Moving the mouse over a table seems to trigger a FullScreenUpdate. > > OK, assume that you managed to get afull repaint (with some scrolling for > example). Now, if you type a character, does it turn the whole work area to > black? > Yes (except for some insets, as always) and when in a table the whole table remains normal. > JMarc smime.p7s Description: S/MIME cryptographic signature
Re: LyX-Workarea: Background not shown correctly
> On 25 Oct 2017, at 12:21, Jean-Marc Lasgouttes wrote: > > Le 23/10/2017 à 23:34, Patrick De Visschere a écrit : >> With the patch in place, SingleParUpdate in bufferView::draw is never >> reached. > > So finally you mean that an UpdateRequest is really fired for each update > event (which makes sense :), right? The patch turns every update into a FullScreenUpdate and SingleParUpdate is then obsolete. Every call to viewport()->update() leads to a QEvent::updateRequest I guess. > >>> It would be interesting to set a break on QWindow::requestUpdate and see >>> whether to is something we do that triggers this effect. >> I did and it’s never triggered. > > OK. btw this was about the function requestUpdate(), not the QEvent. > >>>> If I pass the coordinates of the paragraph, I notice that >>>> “SingleParUpdate" actually means “SingleRowUpdate". Since only the >>>> current paragraph is painted black now, except for the current row. > > What happens is that the painting code (in TextMetrics::drawParagraph) only > paints the rows of the paragraph that have changed. This is why you see that > only the row cursor is repainted. If you do a change that changes the cursor > row and the next one (by inserting a character), you should see several rows > repainted. Yes I found the crcCheck on a row. But when forcing a FullScreenUpdate this code becomes useless, since with pi.full_repaint=true every line is redrawn. > > I do not like much the idea of just restricting the update area, since it > seems very fragile. But we can return to it if needed. There are ways to get > all the coordinates that we need. I agree. The dimensions passed via update(x,y,w,h) and the actual area painted must match exactly. I cannot judge the penalty of the screen redraws. I doesn’t seem to hurt very much. Nevertheless I have now something which works mostly. There are still problems when dragging a selection but I believe these can be solved by fine tuning. The other problem is that when opening a document the screen stil turns black. > > There is a point that I would like to clear though: is the screen turned to > black at each event (insertion of a character...), or only when certain > things happen, like the example of doing a PDF preview like Stephan described > at the beginning of this thread? When typing, the whole screen stays black, except for the current line, which looks normal. You don’t have to do anything special to get this. That’s what I expect: when typing a single character in a row, only that row will be repainted but the update() triggers a full screen erase. With a big document it’s sufficient to scroll a little bit to trigger a FullScreenUpdate. So maybe when not typing and moving the mouse around it might not always be obvious. And within a table there is no problem, meaning that the cells do not turn black. Moving the mouse over a table seems to trigger a FullScreenUpdate. > >> I’m still having problems with the basics. I thought there existed a >> document describing the basics of textMetrics, paragraphMetrics … . >> I found something on the wiki but not so much. > > Did you take a look at development/PAINTING_ANALYSIS? I try to maintain it > while doing changes, but it is incomplete, and probably wrong in some places. Yes I found that and it helped. > > JMarc smime.p7s Description: S/MIME cryptographic signature
Re: LyX-Workarea: Background not shown correctly
> > Can you try to set/unset documentMode in DragTabBar::DragTabBar and see what > it does? > > JMarc I’ve inserted setDocumentMode(true/false); and it doesn’t make any difference. I’ve then set breakpoints in : QCocoaNativeInterface::setContentBorderEnabled(QWindow *window, bool enable) and QMainWindow::setUnifiedTitleAndToolBarOnMac(bool set) but these are never triggered ... … because the format() you’ve been following is not from QCocoaBackingStore, but from QRasterBackingStore, as shown in this stack ... … and that’s because the code for the QCocoaBackingStore::format() has changed between Qt-5.9 and Qt-5.10; This is the code for Qt-5.10: QImage::Format QCocoaBackingStore::format() const { if (windowHasUnifiedToolbar()) return QImage::Format_ARGB32_Premultiplied; return QRasterBackingStore::format(); } === The top routine in the stack QSurfaceFormat::hasAlpha() returns: return d->alphaBufferSize > 0; (with alphaBufferSize=8) The latter is set in : QSurfaceFormat QCocoaWindow::format() const { QSurfaceFormat format = window()->requestedFormat(); // Upgrade the default surface format to include an alpha channel. The default RGB format // causes Cocoa to spend an unreasonable amount of time converting it to RGBA internally. if (format == QSurfaceFormat()) format.setAlphaBufferSize(8); return format; } ===
commit ca4426e broke macos-build
Commit ca4426e (bugfix #10888) broke (at least my) macos-build (qt5.10 and macos 10.12); A change from menu to menuptr in Menus.cpp escaped attention. patch included. pdv menutomenuptr.diff Description: Binary data
Re: Document Settings dialog partially broken on macos
With “not highlighted” I meant that they are greyed out. When e.g. I select “Vertical space” in “Text Layout” instead of the default “Indentation” the OK, Apply and Reset buttons remain greyed out. Apparently the problem is that the screen is not updated immediately: when I subsequently resize the window (or switch to another app), then the display is shown properly. Since you have no problem with Qt-5.9, I then checked with Qt-5.10.1 and there is no problem with that. So, it seems a problem which occurs with Qt-5.11 only. > On 4 Oct 2018, at 19:17, Stephan Witt wrote: > > Am 04.10.2018 um 14:36 schrieb pdv : >> >> Jean-Marc, >> >> I noticed that the Document Settings dialog is partially broken in macos >> (build with Qt-5.11.2). >> >> When making a change to the settings (with the default document class) the >> buttons (OK, apply, reset) are not highlighted. They seem still active >> though, so you can click on them. >> When choosing another document class they become highlighted. >> >> The problem is absent in commit azf... (8/7/2018) and present in commit >> b21... (10/7/2018) and I suppose it's related to the changes in >> QDialogButtonBox. > > If I run current master (as of change 7cb0284a3f) on Mac build with Qt 5.9.4 > I cannot see what you describe. With highlighted you mean enabled? The > buttons get enabled on changing something to the settings. > > Stephan
Re: LyX+Qt5 build (CMake+XCode) on OS X
On 15 Aug, 2014, at 13:57 , Stephan Witt wrote: > Am 12.08.2014 um 22:07 schrieb pdv : > >> As a follow-up on reports in the thread "LyX on OS X 10.9" from some months >> ago, I build LyX(master) + Qt5(stable) (CMake + XCode). >> >> I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by QProxyStyle and >> observed then (at least) 2 issues: >> >> 1) When starting up the menu bar is not visible; One must switch to another >> app and then bring lyx to the foreground to make the menu bar appear. >> 2) When closing the (last) window the menu bar disappears mostly, except for >> the LyX menu. This was also reported by Stephan Witt, but I did observe no >> crash. >> >> When closing the last window Qt5 should switch to the "default menu bar" but >> apparently it doesn't find one and creates it's own minimal default menu bar. >> The default menu bar is created by GlobalMenuBar() (in GuiApplication.cpp) >> which has a constructor GlobalMenuBar() : new QMenuBar(0); according to the >> Qt docs the first parent-less QMenuBar created will be used as the default >> menu bar. Apparently Qt5 does not detect the QMenuBar(0) created via a >> subclass; >> >> When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) is >> solved. >> >> GlobalMenuBar() was introduced to override the event() function to handle >> QEvent::ShortcutOverride events but shortcuts seem to work without using the >> GlobalMenuBar (Cmd-Q and Cmd-, work as expected; Cmd-N and Cmd-O only work >> after first activating one of them via the menu, but the latter also happens >> in LyX211 and may not be related to Qt5). Building LyX + Qt4.8.6 confirms >> that GlobalMenuBar's event() is not called when issuing a shortcut with no >> window present. I assume that these standard mac-shortcuts are handled >> automatically by Qt. >> >> If someone wants to check this, see the attached patch, which includes all >> changes (but does not solve issue 1)). >> >> Patrick De Visschere >> > > Hi Patrick, > > the GlobalMenuBar() thing is a wonderful idea! I'm struggling since a while > with the Qt5 build and failed to solve this issue 2. This I did while being > on vacation, so I couldn't answer earlier. > > The issue 1 was solved by Benjamin Piwowar already, IMHO. It's caused by Qt5 > not showing a menu top item without any action attached. The latest change is > the dummy action has to be attached to the sub menu after the > addMenu(subMenu) method call. I’ve used commit 453ce611919ff66d8b00bda9a9dcc32f4d38a843, which does include this dummy action, if I’m not mistaken. > > Both issues are regressions of Qt5, IMO. > > The QMacStyle doesn't need to be replaced if LyX is linked with the > QMacExtras framework. > > Regarding the Q_WS_MACX macro replacement I'm not sure what should be done. > > 1. I'd prefer to simply replace Q_WS_MACX with Q_OS_MAC which is available > since 4.6.x at least. > 2. I'd prefer to replace Q_WS_X11 and Q_WS_WIN with Q_OS_X11 and Q_OS_WIN at > the same time but cannot test all platforms. > > This results in the attached patch. It contains some additional changes in > Menu.cpp I introduced while attacking the issue 2. Furthermore I changed > CMakeLists.txt because of some warnings from newer cmake. > > This patch should not be commit as is but in some separate steps. Please, if > someone can try it or comment on it, I'd like to hear other opinions. > With this patch I get basically the same behaviour as I described in my initial message. Without a window being present, Cmd-O and Cmd-N don’t work right away. And the application still starts without the menubar being visible (issue 1), but the shortcuts do work. Patrick De Visschere > Stephan > > <2014-08-15-Qt5.patch>
Re: LyX+Qt5 build (CMake+XCode) on OS X
On 19 Aug, 2014, at 14:12 , Stephan Witt wrote: > Am 17.08.2014 um 20:13 schrieb Patrick De Visschere : > >> On 15 Aug, 2014, at 13:57 , Stephan Witt wrote: >> >>> Am 12.08.2014 um 22:07 schrieb pdv : >>> >>>> As a follow-up on reports in the thread "LyX on OS X 10.9" from some >>>> months ago, I build LyX(master) + Qt5(stable) (CMake + XCode). >>>> >>>> I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by QProxyStyle >>>> and observed then (at least) 2 issues: >>>> >>>> 1) When starting up the menu bar is not visible; One must switch to >>>> another app and then bring lyx to the foreground to make the menu bar >>>> appear. >>>> 2) When closing the (last) window the menu bar disappears mostly, except >>>> for the LyX menu. This was also reported by Stephan Witt, but I did >>>> observe no crash. >>>> >>>> When closing the last window Qt5 should switch to the "default menu bar" >>>> but apparently it doesn't find one and creates it's own minimal default >>>> menu bar. >>>> The default menu bar is created by GlobalMenuBar() (in GuiApplication.cpp) >>>> which has a constructor GlobalMenuBar() : new QMenuBar(0); according to >>>> the Qt docs the first parent-less QMenuBar created will be used as the >>>> default menu bar. Apparently Qt5 does not detect the QMenuBar(0) created >>>> via a subclass; >>>> >>>> When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) is >>>> solved. >>>> >>>> GlobalMenuBar() was introduced to override the event() function to handle >>>> QEvent::ShortcutOverride events but shortcuts seem to work without using >>>> the GlobalMenuBar (Cmd-Q and Cmd-, work as expected; Cmd-N and Cmd-O only >>>> work after first activating one of them via the menu, but the latter also >>>> happens in LyX211 and may not be related to Qt5). Building LyX + Qt4.8.6 >>>> confirms that GlobalMenuBar's event() is not called when issuing a >>>> shortcut with no window present. I assume that these standard >>>> mac-shortcuts are handled automatically by Qt. >>>> >>>> If someone wants to check this, see the attached patch, which includes all >>>> changes (but does not solve issue 1)). >>>> >>>> Patrick De Visschere >>>> >>> >>> Hi Patrick, >>> >>> the GlobalMenuBar() thing is a wonderful idea! I'm struggling since a while >>> with the Qt5 build and failed to solve this issue 2. This I did while being >>> on vacation, so I couldn't answer earlier. >>> >>> The issue 1 was solved by Benjamin Piwowar already, IMHO. It's caused by >>> Qt5 not showing a menu top item without any action attached. The latest >>> change is the dummy action has to be attached to the sub menu after the >>> addMenu(subMenu) method call. >> >> I’ve used commit 453ce611919ff66d8b00bda9a9dcc32f4d38a843, which does >> include this dummy action, if I’m not mistaken. > > Yes, me too. But this dummy action is added before the addMenu(menu) method > call. I've had to move it the addAction call after the addMenu call. > >>> Both issues are regressions of Qt5, IMO. >>> >>> The QMacStyle doesn't need to be replaced if LyX is linked with the >>> QMacExtras framework. >>> >>> Regarding the Q_WS_MACX macro replacement I'm not sure what should be done. >>> >>> 1. I'd prefer to simply replace Q_WS_MACX with Q_OS_MAC which is available >>> since 4.6.x at least. >>> 2. I'd prefer to replace Q_WS_X11 and Q_WS_WIN with Q_OS_X11 and Q_OS_WIN >>> at the same time but cannot test all platforms. >>> >>> This results in the attached patch. It contains some additional changes in >>> Menu.cpp I introduced while attacking the issue 2. Furthermore I changed >>> CMakeLists.txt because of some warnings from newer cmake. >>> >>> This patch should not be commit as is but in some separate steps. Please, >>> if someone can try it or comment on it, I'd like to hear other opinions. >>> >> >> With this patch I get basically the same behaviour as I described in my >> initial message. Without a window being present, Cmd-O and Cmd-N don’t work >> right away. And the application still starts without th
Re: LyX+Qt5 build (CMake+XCode) on OS X
On 20 Aug, 2014, at 08:40 , Stephan Witt wrote: > Am 19.08.2014 um 22:41 schrieb Patrick De Visschere : > >> >> On 19 Aug, 2014, at 14:12 , Stephan Witt wrote: >> >>> Am 17.08.2014 um 20:13 schrieb Patrick De Visschere : >>> >>>> On 15 Aug, 2014, at 13:57 , Stephan Witt wrote: >>>> >>>>> Am 12.08.2014 um 22:07 schrieb pdv : >>>>> >>>>>> As a follow-up on reports in the thread "LyX on OS X 10.9" from some >>>>>> months ago, I build LyX(master) + Qt5(stable) (CMake + XCode). >>>>>> >>>>>> I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by QProxyStyle >>>>>> and observed then (at least) 2 issues: >>>>>> >>>>>> 1) When starting up the menu bar is not visible; One must switch to >>>>>> another app and then bring lyx to the foreground to make the menu bar >>>>>> appear. >>>>>> 2) When closing the (last) window the menu bar disappears mostly, except >>>>>> for the LyX menu. This was also reported by Stephan Witt, but I did >>>>>> observe no crash. >>>>>> >>>>>> When closing the last window Qt5 should switch to the "default menu bar" >>>>>> but apparently it doesn't find one and creates it's own minimal default >>>>>> menu bar. >>>>>> The default menu bar is created by GlobalMenuBar() (in >>>>>> GuiApplication.cpp) which has a constructor GlobalMenuBar() : new >>>>>> QMenuBar(0); according to the Qt docs the first parent-less QMenuBar >>>>>> created will be used as the default menu bar. Apparently Qt5 does not >>>>>> detect the QMenuBar(0) created via a subclass; >>>>>> >>>>>> When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) is >>>>>> solved. >>>>>> >>>>>> GlobalMenuBar() was introduced to override the event() function to >>>>>> handle QEvent::ShortcutOverride events but shortcuts seem to work >>>>>> without using the GlobalMenuBar (Cmd-Q and Cmd-, work as expected; Cmd-N >>>>>> and Cmd-O only work after first activating one of them via the menu, but >>>>>> the latter also happens in LyX211 and may not be related to Qt5). >>>>>> Building LyX + Qt4.8.6 confirms that GlobalMenuBar's event() is not >>>>>> called when issuing a shortcut with no window present. I assume that >>>>>> these standard mac-shortcuts are handled automatically by Qt. >>>>>> >>>>>> If someone wants to check this, see the attached patch, which includes >>>>>> all changes (but does not solve issue 1)). >>>>>> >>>>>> Patrick De Visschere >>>>>> >>>>> >>>>> Hi Patrick, >>>>> >>>>> the GlobalMenuBar() thing is a wonderful idea! I'm struggling since a >>>>> while with the Qt5 build and failed to solve this issue 2. This I did >>>>> while being on vacation, so I couldn't answer earlier. >>>>> >>>>> The issue 1 was solved by Benjamin Piwowar already, IMHO. It's caused by >>>>> Qt5 not showing a menu top item without any action attached. The latest >>>>> change is the dummy action has to be attached to the sub menu after the >>>>> addMenu(subMenu) method call. >>>> >>>> I’ve used commit 453ce611919ff66d8b00bda9a9dcc32f4d38a843, which does >>>> include this dummy action, if I’m not mistaken. >>> >>> Yes, me too. But this dummy action is added before the addMenu(menu) method >>> call. I've had to move it the addAction call after the addMenu call. >>> >>>>> Both issues are regressions of Qt5, IMO. >>>>> >>>>> The QMacStyle doesn't need to be replaced if LyX is linked with the >>>>> QMacExtras framework. >>>>> >>>>> Regarding the Q_WS_MACX macro replacement I'm not sure what should be >>>>> done. >>>>> >>>>> 1. I'd prefer to simply replace Q_WS_MACX with Q_OS_MAC which is >>>>> available since 4.6.x at least. >>>>> 2. I'd prefer to replace Q_WS_X11 and Q_WS_WIN with Q_OS_X11 and Q_OS_WIN >>>>> at the sa
Re: LyX+Qt5 build (CMake+XCode) on OS X
On 20 Aug, 2014, at 11:22 , Stephan Witt wrote: > Am 19.08.2014 um 22:41 schrieb Patrick De Visschere : > >> On 19 Aug, 2014, at 14:12 , Stephan Witt wrote: >> >>> Am 17.08.2014 um 20:13 schrieb Patrick De Visschere : >> >> My environment >> >> * Mac OS X 10.9.4 >> * Darwin Kernel Version 13.3.0 >> * Qt 5.3.1 (stable branch) (default Cocoa) >> ./configure -opensource -silent -shared -release -no-dbus -nomake examples >> -nomake tools -no-framework > > You don't build the libraries as frameworks. I'm not sure if this makes no > difference. > > I'm using the Qt frameworks I've build myself. > > Stephan Stephan, I was planning to do that. (the qt-debug build does not make a difference as you expected) I suppose you use the LyX-Mac-binary-release.sh script. I have never managed to use this script without making changes to it, perhaps because I’m using it the wrong way. I build qt as a framework separately and would then use the script like: sh development/LyX-Mac-binary-release.sh --with-qt-frameworks=yes --with-qt-dir=/Users/pdv/Developer/public/Trolltech/Qt-5.3.1 --qt-deployment=yes --with-macosx-target=10.8 --with-sdkroot=10.8 --with-arch=x86_64 --with-libiconv-prefix=/opt/local --enable-debug I think the --with-qt-frameworks=yes is needed to include qt as a framework; and --with-qt-dir=/… points to the dir where the qt-framework has been installed (previously). I’m not sure about the exact meaning of --qt-deployment=yes but I think I need it too. What I don’t understand are the lines 260-262 if [ "${configure_qt_frameworks}" != "yes" ]; then QtInstallDir=${QTDIR:-"/opt/qt4"} fi with --with-qt-frameworks=yes, QtInstallDir is not set. Therefore I uncomment the if/fi so that QtInstallDir=${QTDIR:-"/opt/qt4”} is always executed and QtInstallDir points to my qt-install dir. In addition I must modify some CPPFLAGS= ... Any idea what I’m doing wrong? Patrick De Visschere
Re: LyX+Qt5 build (CMake+XCode) on OS X
On 20 Aug, 2014, at 22:40 , Stephan Witt wrote: > Am 20.08.2014 um 20:46 schrieb Patrick De Visschere : > >> On 20 Aug, 2014, at 08:40 , Stephan Witt wrote: >> >>> Am 19.08.2014 um 22:41 schrieb Patrick De Visschere : >>> >>>> On 19 Aug, 2014, at 14:12 , Stephan Witt wrote: >>>> >>>>> Am 17.08.2014 um 20:13 schrieb Patrick De Visschere >>>>> : >>>>> >>>>>> On 15 Aug, 2014, at 13:57 , Stephan Witt wrote: >>>>>> >>>>>>> Am 12.08.2014 um 22:07 schrieb pdv : >>>>>>> >>>>>>>> As a follow-up on reports in the thread "LyX on OS X 10.9" from some >>>>>>>> months ago, I build LyX(master) + Qt5(stable) (CMake + XCode). >>>>>>>> >>>>>>>> I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by >>>>>>>> QProxyStyle and observed then (at least) 2 issues: >>>>>>>> >>>>>>>> 1) When starting up the menu bar is not visible; One must switch to >>>>>>>> another app and then bring lyx to the foreground to make the menu bar >>>>>>>> appear. >>>>>>>> 2) When closing the (last) window the menu bar disappears mostly, >>>>>>>> except for the LyX menu. This was also reported by Stephan Witt, but I >>>>>>>> did observe no crash. >>>>>>>> >>>>>>>> When closing the last window Qt5 should switch to the "default menu >>>>>>>> bar" but apparently it doesn't find one and creates it's own minimal >>>>>>>> default menu bar. >>>>>>>> The default menu bar is created by GlobalMenuBar() (in >>>>>>>> GuiApplication.cpp) which has a constructor GlobalMenuBar() : new >>>>>>>> QMenuBar(0); according to the Qt docs the first parent-less QMenuBar >>>>>>>> created will be used as the default menu bar. Apparently Qt5 does not >>>>>>>> detect the QMenuBar(0) created via a subclass; >>>>>>>> >>>>>>>> When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) is >>>>>>>> solved. >>>>>>>> >>>>>>>> GlobalMenuBar() was introduced to override the event() function to >>>>>>>> handle QEvent::ShortcutOverride events but shortcuts seem to work >>>>>>>> without using the GlobalMenuBar (Cmd-Q and Cmd-, work as expected; >>>>>>>> Cmd-N and Cmd-O only work after first activating one of them via the >>>>>>>> menu, but the latter also happens in LyX211 and may not be related to >>>>>>>> Qt5). Building LyX + Qt4.8.6 confirms that GlobalMenuBar's event() is >>>>>>>> not called when issuing a shortcut with no window present. I assume >>>>>>>> that these standard mac-shortcuts are handled automatically by Qt. >>>>>>>> >>>>>>>> If someone wants to check this, see the attached patch, which includes >>>>>>>> all changes (but does not solve issue 1)). >>>>>>>> >>>>>>>> Patrick De Visschere >>>>>>>> >>>>>>> >>>>>>> Hi Patrick, >>>>>>> >>>>>>> the GlobalMenuBar() thing is a wonderful idea! I'm struggling since a >>>>>>> while with the Qt5 build and failed to solve this issue 2. This I did >>>>>>> while being on vacation, so I couldn't answer earlier. >>>>>>> >>>>>>> The issue 1 was solved by Benjamin Piwowar already, IMHO. It's caused >>>>>>> by Qt5 not showing a menu top item without any action attached. The >>>>>>> latest change is the dummy action has to be attached to the sub menu >>>>>>> after the addMenu(subMenu) method call. >>>>>> >>>>>> I’ve used commit 453ce611919ff66d8b00bda9a9dcc32f4d38a843, which does >>>>>> include this dummy action, if I’m not mistaken. >>>>> >>>>> Yes, me too. But this dummy action is added before the addMenu(menu) >>>>> method call. I've had to move it the addAction call after the addMenu >>
Re: LyX+Qt5 build (CMake+XCode) on OS X
On 20 Aug, 2014, at 23:15 , Stephan Witt wrote: > Am 20.08.2014 um 22:45 schrieb Patrick De Visschere : > >> On 20 Aug, 2014, at 11:22 , Stephan Witt wrote: >> >>> Am 19.08.2014 um 22:41 schrieb Patrick De Visschere : >>> >>>> On 19 Aug, 2014, at 14:12 , Stephan Witt wrote: >>>> >>>>> Am 17.08.2014 um 20:13 schrieb Patrick De Visschere >>>>> : >>>> >>>> My environment >>>> >>>> * Mac OS X 10.9.4 >>>> * Darwin Kernel Version 13.3.0 >>>> * Qt 5.3.1 (stable branch) (default Cocoa) >>>> ./configure -opensource -silent -shared -release -no-dbus -nomake examples >>>> -nomake tools -no-framework >>> >>> You don't build the libraries as frameworks. I'm not sure if this makes no >>> difference. >>> >>> I'm using the Qt frameworks I've build myself. >>> >>> Stephan >> >> Stephan, >> >> I was planning to do that. (the qt-debug build does not make a difference as >> you expected) >> >> I suppose you use the LyX-Mac-binary-release.sh script. >> >> I have never managed to use this script without making changes to it, >> perhaps because I’m using it the wrong way. >> >> I build qt as a framework separately and would then use the script like: >> >> sh development/LyX-Mac-binary-release.sh --with-qt-frameworks=yes >> --with-qt-dir=/Users/pdv/Developer/public/Trolltech/Qt-5.3.1 >> --qt-deployment=yes --with-macosx-target=10.8 --with-sdkroot=10.8 >> --with-arch=x86_64 --with-libiconv-prefix=/opt/local --enable-debug >> >> I think the --with-qt-frameworks=yes is needed to include qt as a framework; >> >> and --with-qt-dir=/… points to the dir where the qt-framework has been >> installed (previously). >> >> I’m not sure about the exact meaning of --qt-deployment=yes but I think I >> need it too. >> >> What I don’t understand are the lines 260-262 >> if [ "${configure_qt_frameworks}" != "yes" ]; then >> QtInstallDir=${QTDIR:-"/opt/qt4"} >> fi >> >> with --with-qt-frameworks=yes, QtInstallDir is not set. >> >> Therefore I uncomment the if/fi so that >> QtInstallDir=${QTDIR:-"/opt/qt4”} >> >> is always executed and QtInstallDir points to my qt-install dir. >> >> In addition I must modify some CPPFLAGS= ... >> >> Any idea what I’m doing wrong? >> >> Patrick De Visschere > > Perhaps I should remove the --with-qt-frameworks switch. I don't use it > anymore > and it was meant as "with the frameworks by Qt (Nokia)". The > --qt-deployment=yes > is default and with it the script copies the frameworks to the package. This > is > needed if you want to use the LyX app on another system. > > I'd avoid the --with-libiconv-prefix=/opt/local switch. > > This is the shell script I'm using for calling LyX-Mac-binary-release.sh: > > #!/bin/sh > ARCH=x86_64 > QtVersion=5.3.1 > QtAPI=-cocoa > LyXVersion=lyx > CC=cc CXX=c++ \ > QtConfigureOptions="-debug-and-release" QtAPI=${QtAPI} QtVersion=${QtVersion} > \ > sh ${MKFLAGS} ${LyXVersion}/development/LyX-Mac-binary-release.sh \ > --with-sdkroot=10.8 --with-macosx-target=10.6 --with-arch=${ARCH} \ > --with-qt-dir=/Users/Shared/LyX/qt-${QtVersion}-frameworks${QtAPI}-${ARCH} \ > "$@" > > Stephan I’ve build LyX+Qt5 with the LyX-Mac-binary-release.sh script and the menubar appears immediately. Since with XCode I use the macports iconv library that could still theoretically be the culprit. Or maybe it’s just due to Xcode. Anyway this is not very important; I tried to build (with Xcode) without aspell and hunspell but somehow cmake doesn’t want that. There were/are still some problems (with the manual build): 1) Aspell as it is fails to build (on 10.9 I assume). This is easily solved by applying the small patch used by macports. 2) I don’t understand how the lyx-build is supposed to find the Qt5-frameworks; Apparently the switches --enable-qt5 --with-qt-dir=/Users/pdv/Developer/public/Trolltech/Qt-5.3.1 are not sufficient. As before I changed the FLAGS in the script as follows (this is around line 610 of the script) if [ "$configure_qt_frameworks" = "yes" ]; then export QT_CORE_CFLAGS="-FQtCore" export QT_CORE_LIBS="-framework QtCore" export QT_FRONTEND_CFLAGS="-FQtGui" export QT_FRONTEND_LI
Re: LyX+Qt5 build (CMake+XCode) on OS X
On 23 Aug, 2014, at 14:50 , Stephan Witt wrote: > Am 23.08.2014 um 12:01 schrieb Patrick De Visschere : > >> On 20 Aug, 2014, at 23:15 , Stephan Witt wrote: >> >>> Am 20.08.2014 um 22:45 schrieb Patrick De Visschere : >>> >>>> On 20 Aug, 2014, at 11:22 , Stephan Witt wrote: >>>> >>>>> Am 19.08.2014 um 22:41 schrieb Patrick De Visschere >>>>> : >>>>> >>>>>> On 19 Aug, 2014, at 14:12 , Stephan Witt wrote: >>>>>> >>>>>>> Am 17.08.2014 um 20:13 schrieb Patrick De Visschere >>>>>>> : >>>>>> >>>>>> My environment >>>>>> >>>>>> * Mac OS X 10.9.4 >>>>>> * Darwin Kernel Version 13.3.0 >>>>>> * Qt 5.3.1 (stable branch) (default Cocoa) >>>>>> ./configure -opensource -silent -shared -release -no-dbus -nomake >>>>>> examples -nomake tools -no-framework >>>>> >>>>> You don't build the libraries as frameworks. I'm not sure if this makes >>>>> no difference. >>>>> >>>>> I'm using the Qt frameworks I've build myself. >>>>> >>>>> Stephan >>>> >>>> Stephan, >>>> >>>> I was planning to do that. (the qt-debug build does not make a difference >>>> as you expected) >>>> >>>> I suppose you use the LyX-Mac-binary-release.sh script. >>>> >>>> I have never managed to use this script without making changes to it, >>>> perhaps because I’m using it the wrong way. >>>> >>>> I build qt as a framework separately and would then use the script like: >>>> >>>> sh development/LyX-Mac-binary-release.sh --with-qt-frameworks=yes >>>> --with-qt-dir=/Users/pdv/Developer/public/Trolltech/Qt-5.3.1 >>>> --qt-deployment=yes --with-macosx-target=10.8 --with-sdkroot=10.8 >>>> --with-arch=x86_64 --with-libiconv-prefix=/opt/local --enable-debug >>>> >>>> I think the --with-qt-frameworks=yes is needed to include qt as a >>>> framework; >>>> >>>> and --with-qt-dir=/… points to the dir where the qt-framework has been >>>> installed (previously). >>>> >>>> I’m not sure about the exact meaning of --qt-deployment=yes but I think >>>> I need it too. >>>> >>>> What I don’t understand are the lines 260-262 >>>> if [ "${configure_qt_frameworks}" != "yes" ]; then >>>>QtInstallDir=${QTDIR:-"/opt/qt4"} >>>> fi >>>> >>>> with --with-qt-frameworks=yes, QtInstallDir is not set. >>>> >>>> Therefore I uncomment the if/fi so that >>>> QtInstallDir=${QTDIR:-"/opt/qt4”} >>>> >>>> is always executed and QtInstallDir points to my qt-install dir. >>>> >>>> In addition I must modify some CPPFLAGS= ... >>>> >>>> Any idea what I’m doing wrong? >>>> >>>> Patrick De Visschere >>> >>> Perhaps I should remove the --with-qt-frameworks switch. I don't use it >>> anymore >>> and it was meant as "with the frameworks by Qt (Nokia)". The >>> --qt-deployment=yes >>> is default and with it the script copies the frameworks to the package. >>> This is >>> needed if you want to use the LyX app on another system. >>> >>> I'd avoid the --with-libiconv-prefix=/opt/local switch. >>> >>> This is the shell script I'm using for calling LyX-Mac-binary-release.sh: >>> >>> #!/bin/sh >>> ARCH=x86_64 >>> QtVersion=5.3.1 >>> QtAPI=-cocoa >>> LyXVersion=lyx >>> CC=cc CXX=c++ \ >>> QtConfigureOptions="-debug-and-release" QtAPI=${QtAPI} >>> QtVersion=${QtVersion} \ >>> sh ${MKFLAGS} ${LyXVersion}/development/LyX-Mac-binary-release.sh \ >>> --with-sdkroot=10.8 --with-macosx-target=10.6 --with-arch=${ARCH} \ >>> --with-qt-dir=/Users/Shared/LyX/qt-${QtVersion}-frameworks${QtAPI}-${ARCH} >>> \ >>> "$@" >>> >>> Stephan >> >> I’ve build LyX+Qt5 with the LyX-Mac-binary-release.sh script and the menubar >> appears immediately. Since with XCode I use the macports iconv library that >> could still theoretically be the culprit. Or maybe i
Re: LyX+Qt5 build (CMake+XCode) on OS X
Sent from my iPad > On 25 Aug 2014, at 07:55, Stephan Witt wrote: > >> Am 23.08.2014 um 18:01 schrieb Patrick De Visschere : >> >>> On 23 Aug, 2014, at 14:50 , Stephan Witt wrote: >>> >>>> Am 23.08.2014 um 12:01 schrieb Patrick De Visschere >>>> : >>>> >>>>> On 20 Aug, 2014, at 23:15 , Stephan Witt wrote: >>>>> >>>>>> Am 20.08.2014 um 22:45 schrieb Patrick De Visschere >>>>>> : >>>>>> >>>>>>> On 20 Aug, 2014, at 11:22 , Stephan Witt wrote: >>>>>>> >>>>>>>> Am 19.08.2014 um 22:41 schrieb Patrick De Visschere >>>>>>>> : >>>>>>>> >>>>>>>>> On 19 Aug, 2014, at 14:12 , Stephan Witt wrote: >>>>>>>>> >>>>>>>>> Am 17.08.2014 um 20:13 schrieb Patrick De Visschere >>>>>>>>> : >>>>>>>> >>>>>>>> My environment >>>>>>>> >>>>>>>> * Mac OS X 10.9.4 >>>>>>>> * Darwin Kernel Version 13.3.0 >>>>>>>> * Qt 5.3.1 (stable branch) (default Cocoa) >>>>>>>> ./configure -opensource -silent -shared -release -no-dbus -nomake >>>>>>>> examples -nomake tools -no-framework >>>>>>> >>>>>>> You don't build the libraries as frameworks. I'm not sure if this makes >>>>>>> no difference. >>>>>>> >>>>>>> I'm using the Qt frameworks I've build myself. >>>>>>> >>>>>>> Stephan >>>>>> >>>>>> Stephan, >>>>>> >>>>>> I was planning to do that. (the qt-debug build does not make a >>>>>> difference as you expected) >>>>>> >>>>>> I suppose you use the LyX-Mac-binary-release.sh script. >>>>>> >>>>>> I have never managed to use this script without making changes to it, >>>>>> perhaps because I’m using it the wrong way. >>>>>> >>>>>> I build qt as a framework separately and would then use the script like: >>>>>> >>>>>> sh development/LyX-Mac-binary-release.sh --with-qt-frameworks=yes >>>>>> --with-qt-dir=/Users/pdv/Developer/public/Trolltech/Qt-5.3.1 >>>>>> --qt-deployment=yes --with-macosx-target=10.8 --with-sdkroot=10.8 >>>>>> --with-arch=x86_64 --with-libiconv-prefix=/opt/local --enable-debug >>>>>> >>>>>> I think the --with-qt-frameworks=yes is needed to include qt as a >>>>>> framework; >>>>>> >>>>>> and --with-qt-dir=/… points to the dir where the qt-framework has been >>>>>> installed (previously). >>>>>> >>>>>> I’m not sure about the exact meaning of --qt-deployment=yes but I think >>>>>> I need it too. >>>>>> >>>>>> What I don’t understand are the lines 260-262 >>>>>> if [ "${configure_qt_frameworks}" != "yes" ]; then >>>>>>QtInstallDir=${QTDIR:-"/opt/qt4"} >>>>>> fi >>>>>> >>>>>> with --with-qt-frameworks=yes, QtInstallDir is not set. >>>>>> >>>>>> Therefore I uncomment the if/fi so that >>>>>> QtInstallDir=${QTDIR:-"/opt/qt4”} >>>>>> >>>>>> is always executed and QtInstallDir points to my qt-install dir. >>>>>> >>>>>> In addition I must modify some CPPFLAGS= ... >>>>>> >>>>>> Any idea what I’m doing wrong? >>>>>> >>>>>> Patrick De Visschere >>>>> >>>>> Perhaps I should remove the --with-qt-frameworks switch. I don't use it >>>>> anymore >>>>> and it was meant as "with the frameworks by Qt (Nokia)". The >>>>> --qt-deployment=yes >>>>> is default and with it the script copies the frameworks to the package. >>>>> This is >>>>> needed if you want to use the LyX app on another system. >>>>> >>>>> I'd avoid the --with-libiconv-prefix=/opt/local switch. >>>>> >