On Thu, Dec 17, 2020 at 09:52:02AM -0500, Scott Kostyshak wrote:
> On Thu, Dec 17, 2020 at 11:39:17AM +0100, Jean-Marc Lasgouttes wrote:
> > Le 30/10/2020 à 13:13, Jean-Marc Lasgouttes a écrit :
> > > Le 25/10/2020 à 03:58, Richard Kimberly Heck a écrit :
> > > > On 10/24/20 2:17 PM, Jean-Marc
Boost is not, the others in 3rdparty are not encapsulated but used only in a
few place.
If you want to keep a header file, the best is probably to put everything in
namespace lyx.
JMarc
Yes, boost's `assert` is not encapsulated, but `crc` and `any` are.
I've moved all into `lyx`
Le 17/12/2020 à 11:46, Kornel Benko a écrit :
Am Thu, 17 Dec 2020 11:40:36 +0100
schrieb Jean-Marc Lasgouttes :
I guess it can wait for 2.3.7. Looking at "git log" for
3rdparty/hunspell, there is one main commit (c3484fa6c), 2 fixups
(91c58d9a68ca2 and cf980435b), plus a fistful of commits by
Le 07/12/2020 à 19:18, Jean-Marc Lasgouttes a écrit :
Le 02/12/2020 à 15:35, Jürgen Spitzmüller a écrit :
Am Dienstag, dem 01.12.2020 um 10:46 -0500 schrieb Richard Kimberly
Heck:
Jürgen knows the most about this, I think, but my sense is that (2)
is
the way to go. I find the ButtonController
Le 19/12/2020 à 20:05, Yuriy Skalko a écrit :
Since support/signals.h is pretty empty now, why not just use
nod/signal.h and nod::signal? Then we can get rid of the header file.
Patches 2 and 4 are fine.
JMarc
I think that it is better to leave such interfacing header to limit this
Since support/signals.h is pretty empty now, why not just use nod/signal.h and
nod::signal? Then we can get rid of the header file.
Patches 2 and 4 are fine.
JMarc
I think that it is better to leave such interfacing header to limit this
3rd-party dependency in one point (this already
Le 16/12/2020 à 20:37, Yuriy Skalko a écrit :
Great! It is now only 1.5 MB!
Using "signals" conflicts with Qt keyword, so I've used "signal". Also
moved now unneeded for signals class Trackable to the only place where
it is used.
Since support/signals.h is pretty empty now, why not just use
Hi Jean-Marc,
Many thanks for the speedy response.
Something like code-completion but for text.
Press a hotkey, present a popup window with options (which will depend
on where the cursor was on hotkeypress), then execute some action
depending on the user choice that alters the LyX text.
The
Am Sat, 19 Dec 2020 15:52:44 +0200
schrieb Yuriy Skalko :
> >> Just to be sure: Yuriy do you plan to get rid of this signals2
> >> namespace? It
> >> doe snot make much sense.
> >>
> >>
> >> JMarc
> >>
> >
> >
> > Using "signals" conflicts with Qt keyword, so I've used
Just to be sure: Yuriy do you plan to get rid of this signals2 namespace? It
doe snot make much sense.
JMarc
Using "signals" conflicts with Qt keyword, so I've used "signal". Also moved
now unneeded for signals class Trackable to the only place where it is used.
Yuriy
Le 19/12/2020 à 13:38, Christos Liaskos a écrit :
Dear LyX development team,
First of all, many thanks for your hard work! I am an enthusiastic user
of LyX since 2009.
I would like to create a custom plugin. (The goal is to provide
generalized text autocompletion, depending on the context).
Dear LyX development team,
First of all, many thanks for your hard work! I am an enthusiastic user
of LyX since 2009.
I would like to create a custom plugin. (The goal is to provide
generalized text autocompletion, depending on the context).
I have searched for information about developing
12 matches
Mail list logo
