Le 19/11/2022 à 11:38, Jürgen Spitzmüller a écrit :
Am Freitag, dem 18.11.2022 um 17:33 +0100 schrieb Jean-Marc Lasgouttes:
What can you do to help?
* have look at the diff in src to spot what I broke
Looks good from what I can tell.
Thanks for checking.
* and look at KILLQT4 annotations t
Am Freitag, dem 18.11.2022 um 17:33 +0100 schrieb Jean-Marc Lasgouttes:
> What can you do to help?
> * have look at the diff in src to spot what I broke
Looks good from what I can tell.
> * and look at KILLQT4 annotations to see whethe rsome of them are in
> your ballpark
> * look for things to
Le 18/11/2022 à 18:03, Scott Kostyshak a écrit :
What can you do to help?
* have look at the diff in src to spot what I broke
* and look at KILLQT4 annotations to see whethe rsome of them are in your
ballpark
* look for things to do in TODO.killqt4
I think this was meant for Jürgen, but to be c
On Fri, Nov 18, 2022 at 05:33:43PM +0100, Jean-Marc Lasgouttes wrote:
> Le 17/11/2022 à 07:34, Jürgen Spitzmüller a écrit :
> > Am Mittwoch, dem 16.11.2022 um 11:11 -0500 schrieb Scott Kostyshak:
> > > Does anyone object then to supporting only Qt5 for
> > > 2.4.0 (and forward)?
> >
> > No. I thin
Le 17/11/2022 à 07:34, Jürgen Spitzmüller a écrit :
Am Mittwoch, dem 16.11.2022 um 11:11 -0500 schrieb Scott Kostyshak:
Does anyone object then to supporting only Qt5 for
2.4.0 (and forward)?
No. I think now is the time to do it.
I created a new branch killqt4 that removes #ifdefs in src and
Am Mittwoch, dem 16.11.2022 um 11:11 -0500 schrieb Scott Kostyshak:
> Does anyone object then to supporting only Qt5 for
> 2.4.0 (and forward)?
No. I think now is the time to do it.
--
Jürgen
signature.asc
Description: This is a digitally signed message part
--
lyx-devel mailing list
lyx-deve
On Wed, Nov 16, 2022 at 06:03:04PM +0100, Jean-Marc Lasgouttes wrote:
> Le 16/11/2022 à 17:57, Scott Kostyshak a écrit :
> > I don't know. What do others think? Do we go all-in and drop Qt4 and do
> > all the clean up now to simplify the code? That would indeed feel nice.
> >
> > Or do we leave it
Le 16/11/2022 à 17:57, Scott Kostyshak a écrit :
I don't know. What do others think? Do we go all-in and drop Qt4 and do
all the clean up now to simplify the code? That would indeed feel nice.
Or do we leave it as is, and just officially not support Qt4, so that if
some (from what I understand,
On Wed, Nov 16, 2022 at 05:51:30PM +0100, Jean-Marc Lasgouttes wrote:
> Le 16/11/2022 à 17:11, Scott Kostyshak a écrit :
> > On Wed, Nov 16, 2022 at 02:37:18PM +0100, Thibaut Cuvelier wrote:
> >
> > > Well, if barely anyone tests with Qt 4 (I'm only using Qt 5.15), it's
> > > already unsupported i
Le 16/11/2022 à 17:11, Scott Kostyshak a écrit :
On Wed, Nov 16, 2022 at 02:37:18PM +0100, Thibaut Cuvelier wrote:
Well, if barely anyone tests with Qt 4 (I'm only using Qt 5.15), it's
already unsupported in practice and making the necessary changes would be
(1) cumbersome and (2) a waste of re
On Wed, Nov 16, 2022 at 02:37:18PM +0100, Thibaut Cuvelier wrote:
> Well, if barely anyone tests with Qt 4 (I'm only using Qt 5.15), it's
> already unsupported in practice and making the necessary changes would be
> (1) cumbersome and (2) a waste of resources (little gain in supporting
> versions
On Mon, 14 Nov 2022 at 19:38, Scott Kostyshak wrote:
> On Tue, Oct 18, 2022 at 10:51:34AM -0400, Scott Kostyshak wrote:
> > On Tue, Oct 18, 2022 at 03:12:40PM +0200, Pavel Sanda wrote:
> > > On Fri, Oct 07, 2022 at 05:05:43PM +0200, Jean-Marc Lasgouttes wrote:
> > > > Still, I am wondering why we
On Tue, Oct 18, 2022 at 10:51:34AM -0400, Scott Kostyshak wrote:
> On Tue, Oct 18, 2022 at 03:12:40PM +0200, Pavel Sanda wrote:
> > On Fri, Oct 07, 2022 at 05:05:43PM +0200, Jean-Marc Lasgouttes wrote:
> > > Still, I am wondering why we insist on supporting Qt4 for 2.4.0
> > > (especially
> > > co
On Tue, Oct 18, 2022 at 06:27:00PM +0200, Jean-Marc Lasgouttes wrote:
> >That was decided when we planned to release 2.4 at the end of 2019.
> >It's clear we won't be able to push 2.4 even for next debian stable
> >and I think we can relax Qt4 support and move on.
>
> What do you mean by "relax" ?
Le 18/10/2022 à 15:12, Pavel Sanda a écrit :
On Fri, Oct 07, 2022 at 05:05:43PM +0200, Jean-Marc Lasgouttes wrote:
Still, I am wondering why we insist on supporting Qt4 for 2.4.0 (especially
considering that we will have to continue this game for 2+ years after
that).
That was decided when we
On Tue, Oct 18, 2022 at 03:12:40PM +0200, Pavel Sanda wrote:
> On Fri, Oct 07, 2022 at 05:05:43PM +0200, Jean-Marc Lasgouttes wrote:
> > Still, I am wondering why we insist on supporting Qt4 for 2.4.0 (especially
> > considering that we will have to continue this game for 2+ years after
> > that).
On Fri, Oct 07, 2022 at 05:05:43PM +0200, Jean-Marc Lasgouttes wrote:
> Still, I am wondering why we insist on supporting Qt4 for 2.4.0 (especially
> considering that we will have to continue this game for 2+ years after
> that).
That was decided when we planned to release 2.4 at the end of 2019.
Still, I am wondering why we insist on supporting Qt4 for 2.4.0 (especially considering that we will have to continue this game for 2+ years after that).
I join to your wondering. And here is the patch to at least clean
conditional code portions for Qt < 4.8.
Yuriy
From ba021353090922642e0e2
You can use
branchCO->itemData(branchCO->currentIndex()).toString()
This works in Qt 4 and upwards.
Thanks, Jürgen! This way even dedicated Qt4 users will be able to enjoy
this update :)
Committed.
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listin
Am Freitag, dem 07.10.2022 um 18:02 +0300 schrieb Yuriy Skalko:
> Now with "(master)" suffix in combobox labels we cannot use them
> directly as branch names. Is is OK to disable this for Qt4
> alltogether,
> as README says that LyX is only compilable on Qt4?
You can use
branchCO->itemData(bran
Le 07/10/2022 à 17:02, Yuriy Skalko a écrit :
Now with "(master)" suffix in combobox labels we cannot use them
directly as branch names. Is is OK to disable this for Qt4 alltogether,
as README says that LyX is only compilable on Qt4?
This seems like an acceptable solution, if the code is simpl
ames. Is is OK to disable this for Qt4 alltogether,
as README says that LyX is only compilable on Qt4?
Yuriy
From 716cc9991d1025614424b7ceaa6761ab0f817083 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Fri, 7 Oct 2022 17:41:46 +0300
Subject: [PATCH] Show branches from master document in branch inset dialog
---
src/fro
Le 06/10/2022 à 19:39, Yuriy Skalko a écrit :
Hello all,
Currently in LyX you can insert into child documents the insets for
branches defined in master document only. But it is impossible to change
the branch afterwards for such inset because master branches are not
shown in the "Branch Setti
Am Freitag, dem 07.10.2022 um 09:43 +0200 schrieb Jürgen Spitzmüller:
> branchCO->addItem(
> toqstr(bformat( _("%1$s[[branch]]
> (%2$s)[[master]]"),
> toqstr(branch), qt_("master";
that should be _("master") of course.
--
Jürgen
signature.asc
Description: This is a digit
Am Donnerstag, dem 06.10.2022 um 20:39 +0300 schrieb Yuriy Skalko:
> Hello all,
>
> Currently in LyX you can insert into child documents the insets for
> branches defined in master document only. But it is impossible to
> change
> the branch afterwards for such inset because master branches are
fixes this.
Yuriy
From e46a33c41625bc7ca49df53a8bf14997c318f92d Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Thu, 6 Oct 2022 20:24:59 +0300
Subject: [PATCH] Show branches from master document in branch inset dialog
---
src/frontends/qt/GuiBranch.cpp | 31 +++
1 fi
26 matches
Mail list logo
