Misplaced IME window in 2.4.0

2024-03-20 Thread Allan Chain

Hello, LyX developers!

I'm trying out LyX 2.4.0-rc3 (qt6) on KDE6+Wayland, and I'm using fcitx5 
to input CJK characters. I found that the candidate window of the input 
method is always on the top left corner of the window, regardless of the 
cursor position. I think it's a regression since 2.3.7 does not have 
such problem.


After looking into the source code, I found that the position hint 
(Qt::ImCursorRectangle) is only updated when preedit is enabled. 
Although enabling preedit eases the problem, the experience is still not 
very smooth. Specifically, when the position of the cursor is changed, 
for example by clicking, the position hint for the candidate window is 
not immediately updated, and thus the candidate window pops up in a 
wrong position. Only after some keystrokes triggering preedit event that 
the position of the candidate window is correctly updated.


I'm not familiar with LyX codebase, but in my opinion, a better solution 
is to update the position hint for the input method every time the 
cursor position changes.


I'm happy to provide more information to help fixing this.

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: cmake build on macos (Sonoma, XCode) fails and remedy

2024-03-20 Thread Kornel Benko
Am Tue, 19 Mar 2024 15:31:00 +0100
schrieb pdv :

> Using the latest commit and building lyx with cmake on macos-sonoma with 
> xcode fails with multiple error messages like this one:
> 
> --
> CMake Error in po/CMakeLists.txt:
>The custom command generating
> 
>  /po/LyX2.4.cat.pot
> 
>is attached to multiple targets:
> 
>  translations
>  update-gmo
> 
>   but none of these is a common dependency of the other(s).  This is not
>   allowed by the Xcode "new build system".
> ---
> 
> These issues are solved by adding the following target dependencies 
> (patch included)
> 
>   add_dependencies(update-gmo translations)
>   add_dependencies(update-gmo update-po)
> 
>   add_dependencies(cleanupdatetex2lyxtests updatetex2lyxtests)
> 
> 
> pdv

It's in at 3f790725.

Kornel


pgpeiWA5bVpUU.pgp
Description: Digitale Signatur von OpenPGP
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: cmake build with qt6 (macos) does not include "plugins"

2024-03-20 Thread Kornel Benko
Am Sat, 4 Nov 2023 18:05:42 +0100
schrieb pdv :

> On 04/11/2023 17:55, pdv wrote:
> > On 21/03/2023 19:27, Kornel Benko wrote:
> >> Am Tue, 21 Mar 2023 15:27:41 +0100
> >> schrieb pdv :
> >>
> >>> On 21/03/2023 11:00, Kornel Benko wrote:
>  Am Mon, 20 Mar 2023 20:05:32 +0100
>  schrieb pdv :
> > It's within the first if() else(), that's thus for qt6(see below). I
> > suppose this should work for all platforms, but I checked it on macos
> > only. Your patch is limited to APPLE and also works for me; If this
> > problem doesn't occur for other platforms, it's ok for me of course.
> 
>  Probably no one else is using the bundle option (-DLYX_BUNDLE=ON).
> 
>  If you could try to use cmake without this option, I'd be interested 
>  if it works for
>  you too.
> >>>
> >>> Apparently no problem. -DLYX_BUNDLE=OFF works too for me.
> >>>
>  In this case we could get rid of it (probably).
> 
>  Kornel
> 
> >>>
> >>>
> >>
> >> Good, so I will disable this option for lyx2.5 then.
> >>
> >> Kornel
> >>
> >>
> > I have build the latest lyx-master and I still need my (previous) patch 
> > to build a LyX.app which includes all required Qt6 frameworks (I want a 
> > stand-alone app).
> > 
> > I'm using a recent version of CMake and apparently versions older than 
> > 3.5 will not longer be supported. To get rid of the annoying warnings 
> > I've upped the minimum version from 3.1 to 3.5 (new patch included).
> > 
> > pdv
> > 
> Sorry, forgot to include the patch.

I have similar patch ( for all CMakeLists.txt) ready and only waiting for 2.4 
to be out.

Kornel


pgpmn8MSMhSUx.pgp
Description: Digitale Signatur von OpenPGP
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: cmake build with qt6 (macos) does not include "plugins"

2024-03-20 Thread Pavel Sanda
On Tue, Mar 19, 2024 at 04:02:34PM +0100, pdv wrote:
> These steps have been added to my previous patch (new patch included) and I
> also derived the QT_PLUGINS_DIR and QT_LIBRARY_DIRS variables from the
> existing Qt6_DIR/Qt5_DIR variable, so they must not longer be supplied.

I see there is some very old bug related to osx budles, pehaps it should be 
closed?
https://www.lyx.org/trac/ticket/9018

> I only tested this with Qt6.

Unf we are staying out of Qt6 for mac because of serious issues we were not 
able to solve
(see bug https://www.lyx.org/trac/ticket/12641 ).

Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Scheduled maintenance of LyX servers (Mar 21, 2024)

2024-03-20 Thread Pavel Sanda
Dear LyXers,

we plan to do the major transition of our web infrastructure soon.
Web and wiki were already moved to read-only mode, bug tracker (trac) will be
probably inaccesible altogether, probably from Thu morning (all times in CET).
The main switch is planned on Thu evening hours. The optimistic scenario
is that we will finish by midnight.

Git and mailling services should remain intact, you can keep the business
as usual there.

We tried to prepare things ahead, but it's impossible to know all the 
collateral damage until we pull the trigger. So expect evening outage
and I would ask you to avoid unecessery interaction with the services
from Thursday (commenting bugs, changing wiki etc) until I send further 
announcement. Things could be probably more smooth, but time is
currently scarce resource both for me and JMarc.

Fingers crossed :)
Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Layout file format change proposal

2024-03-20 Thread Lorenzo Bertini
Dear devs,
I don't know if this has been discussed before. Lyx uses it's own
format .layout (or .module), with it's own parser. However, the same
information can be easily saved stored in another format. I asked a
chatbot to convert "amsbook.layout" to an hypothetical "amsbook.yaml"
file:

format: 104
columns: 1
sides: 2
page_style: Headers
docbook_root: book
provides:
  - amsmath: 1
  - makeidx: 1
class_options:
  font_size: [8, 9, 10, 11, 12]
default_modules:
  - theorems-ams
  - eqs-within-sections
  - figs-within-sections
styles:
  Standard:
category: MainText
margin: Static
latex_type: Paragraph
latex_name: dummy
par_indent: MM
par_skip: 0.4
align: Block
align_possible: [Block, Left, Right, Center]
label_type: No_Label
docbook_tag: para
preamble: "\numberwithin{section}{chapter}"
inputs:
  - stdsections.inc
  - stdinsets.inc
  - numreport.inc
  - lyxmacros.inc
  - stdlayouts.inc
  - stdlists.inc
  - stdfloats.inc
  - stdcounters.inc
  - amsdefs.inc
unwanted_styles:
  - Verse
  - Bibliography:
  toc_level: 0
styles_append:
  Section:
align: Center
font:
  series: Bold
  size: Large
toc_level: 1
  Subsection:
font:
  series: Bold
  size: Normal
toc_level: 2
  Subsubsection:
font:
  shape: Italic
  size: Normal
toc_level: 3
  Section*:
align: Center
font:
  series: Bold
  size: Large
  Subsection*:
font:
  series: Bold
  size: Normal
  Subsubsection*:
font:
  shape: Italic
  size: Normal
  Paragraph:
font:
  series: Medium
toc_level: 4
  Chapter_Exercises:
margin: First_Dynamic
latex_type: Item_Environment
latex_name: lyxxcb
next_no_indent: 1
left_margin: MMN
label_sep: xx
par_skip: 0.0
item_sep: 0.2
top_sep: 0.7
bottom_sep: 0.7
par_sep: 0.3
align: Block
align_possible: [Block, Left]
label_type: Itemize
label_font:
  shape: Up
  series: Bold
preamble: "\newenvironment{lyxxcb}..."
argument_listpreamble:
  - label_string: "List preamble"
menu_string: "List Preamble"
tooltip: "LaTeX code to be inserted before the first item"
pass_thru: 1
font:
  family: typewriter
  color: latex
docbook_tag: para
docbook_attr: role='chapter-exercises'

I think it looks pretty good. The advantages of using an industry standard are:
1. People already know the format. This could encourage publishers to
provide layouts.
2. Existing and solid tools for parsing can be used. Even if not
directly by LyX, someone manipulating layouts externally doesn't need
to reinvent the wheel.

Let me know what you think.

Lorenzo
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel