Discussion:
[patch] Single Instance LyX
(too old to reply)
Vincent van Ravesteijn
2010-11-12 18:39:42 UTC
Permalink
yes it should be under preferences. personally i would like to run always
without this feature (dont like when crash in one window kill all other windows).
Hmm.. you're working on multiple documents in the same time. Why do we
have the multiple window option then in LyX ? (And I thought you were
a frequent user of that).
btw what happens if one just runs lyx in commandline mode for scripting purposes
like lyx file.lyx -e pdf ...
Nothing, this code only kicks in after we have decided we need a gui.

See LyX::exec, where we bail out earlier when use_gui is false.
pavel
Vincent
Pavel Sanda
2010-11-12 18:31:51 UTC
Permalink
The only thing lacking here is the preference stuff, but someone else could
do that, if you wish.
yes it should be under preferences. personally i would like to run always
without this feature (dont like when crash in one window kill all other windows).

btw what happens if one just runs lyx in commandline mode for scripting purposes
like lyx file.lyx -e pdf ...

pavel
Pavel Sanda
2010-11-12 19:06:08 UTC
Permalink
Post by Vincent van Ravesteijn
yes it should be under preferences. personally i would like to run always
without this feature (dont like when crash in one window kill all other windows).
Hmm.. you're working on multiple documents in the same time. Why do we
have the multiple window option then in LyX ?
ask Abdel ;) i'm upset about this behaviour of firefox and acroread at least
twice a week when other window freeze (firefox) or badly interfere with the
other window (acroread kills menu for all windows when one window ask for it and
similar). so no fan of lyx doing this...
once you have 12 desktops and uptime is in weeks its really no problem to
have many opened sessions for various todos...
Post by Vincent van Ravesteijn
(And I thought you were a frequent user of that).
as user only in case i need to see the same buffer twice. i had very bad
experiences with various crashes and painting incongruences so i'm generally
avoiding this mode except the case above.
Post by Vincent van Ravesteijn
Nothing, this code only kicks in after we have decided we need a gui.
See LyX::exec, where we bail out earlier when use_gui is false.
good.

pavel
Richard Heck
2010-11-12 22:23:24 UTC
Permalink
Here is a complete patch with preferences and command line switches.
It is designed such that an already running instance is contacted only
when a document is to be loaded. So, if you export from command line,
things go as usual.
You can set a preference for the default behavior, but you can also
override the preference setting from the command line. So, I think
this is very flexible and should satisfy any taste.
Without any preference set or command line switch specified, the default
is to try to load documents in an already running instance, as I think
that this the most logical behavior. However, once you untick the
"Single instance" check box in the preferences, LyX behaves exactly as
before the introduction of this feature, such that you should only
experience the bugs that would have anyhow afflicted you.
So, can I commit?
No objection here.

rh
Pavel Sanda
2010-11-13 00:47:22 UTC
Permalink
Post by Richard Heck
Here is a complete patch with preferences and command line switches.
It is designed such that an already running instance is contacted only
when a document is to be loaded. So, if you export from command line,
things go as usual.
You can set a preference for the default behavior, but you can also
override the preference setting from the command line. So, I think
this is very flexible and should satisfy any taste.
Without any preference set or command line switch specified, the default
is to try to load documents in an already running instance, as I think
that this the most logical behavior. However, once you untick the
"Single instance" check box in the preferences, LyX behaves exactly as
before the introduction of this feature, such that you should only
experience the bugs that would have anyhow afflicted you.
So, can I commit?
No objection here.
+1

please also put the description paragraph from above somewhere into
documentation, + item in wiki news.

thanks,
pavel
Enrico Forestieri
2010-11-13 12:09:45 UTC
Permalink
Post by Pavel Sanda
Post by Richard Heck
Here is a complete patch with preferences and command line switches.
It is designed such that an already running instance is contacted only
when a document is to be loaded. So, if you export from command line,
things go as usual.
You can set a preference for the default behavior, but you can also
override the preference setting from the command line. So, I think
this is very flexible and should satisfy any taste.
Without any preference set or command line switch specified, the default
is to try to load documents in an already running instance, as I think
that this the most logical behavior. However, once you untick the
"Single instance" check box in the preferences, LyX behaves exactly as
before the introduction of this feature, such that you should only
experience the bugs that would have anyhow afflicted you.
So, can I commit?
No objection here.
+1
Patch committed at r36278.
Post by Pavel Sanda
please also put the description paragraph from above somewhere into
documentation, + item in wiki news.
I added a note in the NewInLyX20 wiki page but I'd rather not touch
the docs, sorry.
--
Enrico
Jean-Marc Lasgouttes
2010-11-12 22:43:57 UTC
Permalink
Without any preference set or command line switch specified, the
default
is to try to load documents in an already running instance, as I think
that this the most logical behavior. However, once you untick the
"Single instance" check box in the preferences, LyX behaves exactly as
before the introduction of this feature, such that you should only
experience the bugs that would have anyhow afflicted you.
What happens on OS X, where single instance is enforced by the OS?

JMarc
Enrico Forestieri
2010-11-12 22:50:17 UTC
Permalink
Post by Jean-Marc Lasgouttes
Without any preference set or command line switch specified, the
default
is to try to load documents in an already running instance, as I think
that this the most logical behavior. However, once you untick the
"Single instance" check box in the preferences, LyX behaves exactly as
before the introduction of this feature, such that you should only
experience the bugs that would have anyhow afflicted you.
What happens on OS X, where single instance is enforced by the OS?
I don't have access to a Mac, so I don't know. If you are able to
tell me how that is achieved, I could maybe tell you. Anyway, if on Mac
this causes problems, it can be easily disabled for OS X.
--
Enrico
BH
2010-11-13 02:28:07 UTC
Permalink
Post by Enrico Forestieri
Post by Jean-Marc Lasgouttes
Without any preference set or command line switch specified, the
default
is to try to load documents in an already running instance, as I think
that this the most logical behavior. However, once you untick the
"Single instance" check box in the preferences, LyX behaves exactly as
before the introduction of this feature, such that you should only
experience the bugs that would have anyhow afflicted you.
What happens on OS X, where single instance is enforced by the OS?
I don't have access to a Mac, so I don't know. If you are able to
tell me how that is achieved, I could maybe tell you. Anyway, if on Mac
this causes problems, it can be easily disabled for OS X.
I've applied the patch on OS X, and everything seems to work fine for
me. Is there something in particular I should test?

BH
Enrico Forestieri
2010-11-13 11:29:50 UTC
Permalink
Post by BH
Post by Enrico Forestieri
Post by Jean-Marc Lasgouttes
Without any preference set or command line switch specified, the
default
is to try to load documents in an already running instance, as I think
that this the most logical behavior. However, once you untick the
"Single instance" check box in the preferences, LyX behaves exactly as
before the introduction of this feature, such that you should only
experience the bugs that would have anyhow afflicted you.
What happens on OS X, where single instance is enforced by the OS?
I don't have access to a Mac, so I don't know. If you are able to
tell me how that is achieved, I could maybe tell you. Anyway, if on Mac
this causes problems, it can be easily disabled for OS X.
I've applied the patch on OS X, and everything seems to work fine for
me. Is there something in particular I should test?
I don't know how that single instance enforcement is attained, but if
that is true, you should not be able to launch a new instance of lyx
by using the --no-remote switch. So, launch lyx a first time, then try
to get a new instance using "lyx --no-remote". Do you now have two
different instances or not?
--
Enrico
Jean-Marc Lasgouttes
2010-11-13 12:46:28 UTC
Permalink
Post by Enrico Forestieri
I don't know how that single instance enforcement is attained, but if
that is true, you should not be able to launch a new instance of lyx
by using the --no-remote switch. So, launch lyx a first time, then try
to get a new instance using "lyx --no-remote". Do you now have two
different instances or not?
Actually, when LyX is launched via its icon or by double clicking a
document, the lyx binary is invoked with a special (-ss I think)
argument pointing
to the existing instance. The new file to load appears as a window
system message.

So, when launching LyX from the command line, your patch should do
the right thing (tm).

JMarc
Stephan Witt
2010-11-13 12:57:54 UTC
Permalink
Post by Jean-Marc Lasgouttes
Post by Enrico Forestieri
I don't know how that single instance enforcement is attained, but if
that is true, you should not be able to launch a new instance of lyx
by using the --no-remote switch. So, launch lyx a first time, then try
to get a new instance using "lyx --no-remote". Do you now have two
different instances or not?
Actually, when LyX is launched via its icon or by double clicking a
document, the lyx binary is invoked with a special (-ss I think) argument pointing
to the existing instance. The new file to load appears as a window system message.
So, when launching LyX from the command line, your patch should do
the right thing (tm).
I tested it on Mac and it works as it should. With --no-remote a new instance is
started. Otherwise the running LyX opens a new window. I'd say it's ok.

Only rare corner cases - e. g. a stopped LyX instance - may be a problem now.

Stephan
Enrico Forestieri
2010-11-13 13:59:26 UTC
Permalink
Post by Stephan Witt
Post by Jean-Marc Lasgouttes
Post by Enrico Forestieri
I don't know how that single instance enforcement is attained, but if
that is true, you should not be able to launch a new instance of lyx
by using the --no-remote switch. So, launch lyx a first time, then try
to get a new instance using "lyx --no-remote". Do you now have two
different instances or not?
Actually, when LyX is launched via its icon or by double clicking a
document, the lyx binary is invoked with a special (-ss I think) argument pointing
to the existing instance. The new file to load appears as a window system message.
So, when launching LyX from the command line, your patch should do
the right thing (tm).
I tested it on Mac and it works as it should. With --no-remote a new instance is
started. Otherwise the running LyX opens a new window. I'd say it's ok.
Only rare corner cases - e. g. a stopped LyX instance - may be a problem now.
Maybe less than it would appear. If LyX crashed leaving behind a stale pipe,
this is detected and no running instance is assumed to be present. Of course,
if LyX did not crash but is somehow stalled, then we would have the
problem that a document will never be opened, unless using the --no-remote
switch or killing the stalled instance. This is the price to pay for this
feature, I am sorry.
--
Enrico
Stephan Witt
2010-11-14 13:25:14 UTC
Permalink
Post by Enrico Forestieri
Post by Stephan Witt
Post by Jean-Marc Lasgouttes
Post by Enrico Forestieri
I don't know how that single instance enforcement is attained, but if
that is true, you should not be able to launch a new instance of lyx
by using the --no-remote switch. So, launch lyx a first time, then try
to get a new instance using "lyx --no-remote". Do you now have two
different instances or not?
Actually, when LyX is launched via its icon or by double clicking a
document, the lyx binary is invoked with a special (-ss I think) argument pointing
to the existing instance. The new file to load appears as a window system message.
So, when launching LyX from the command line, your patch should do
the right thing (tm).
I tested it on Mac and it works as it should. With --no-remote a new instance is
started. Otherwise the running LyX opens a new window. I'd say it's ok.
Only rare corner cases - e. g. a stopped LyX instance - may be a problem now.
Maybe less than it would appear. If LyX crashed leaving behind a stale pipe,
this is detected and no running instance is assumed to be present. Of course,
if LyX did not crash but is somehow stalled, then we would have the
problem that a document will never be opened, unless using the --no-remote
switch or killing the stalled instance. This is the price to pay for this
feature, I am sorry.
Yes, I didn't want to search for problems. It was meant as a praise.

Stephan

Richard Heck
2010-11-10 18:35:22 UTC
Permalink
Hi all,
These two patches implement a single instance LyX.
Nice work!
I can add some preference options.
- What kind of preference do we need ?
A preference to enable or disable this kind of behavior. So:

if (lyxrc.single_instance && pimpl_->application_->isRunning()) {
...
- Do we want to include the code for QtSingleApplication in our tree ?
What is the alternative?
- We then depend on QtNetwork.dll/lib and should be included in the installers.
- The actual action to be taken by the instance has to be implemented stil.
Comments ?
On the issue of whether it is included in 2.0, looking at the
QtSingleApplication class, it seems to be a pretty simple extension of
QApplication, so I don't think the switch is likely to cause problems.
Still, it needs testing. I would think you could #if most of the
necessary code fairly easily, and then people can try if it they like,
as we did for EXPORT_in_THREAD. The one thing I would do is put the
preference setting in now in LyXRC.cpp, but with no UI for setting it.
Then, even if we thought it wasn't ready for 2.0, it could still get
into the 2.0.x series, since we'd have done the format change. The
preference could be enabled by default, for now, since anyone who
compiles with USE_SINGLE_INSTANCE=1 will surely want it on, and of
course they can disable it by editing the prefs file.

Even better, in a way, would be to make the configurable via ./configure
--enable-single-instance. Then packagers could choose what to do. I
think single instance makes a lot of sense on Windows, less so on Linux,
since it's easy to get that behavior if you want via scripts.

Richard
Enrico Forestieri
2010-11-10 19:12:15 UTC
Permalink
These two patches implement a single instance LyX.
Comments ?
Pavel,
Do you think it has a chance to make it into 2.0.0 ?
I think no, if we follow the rules.
--
Enrico
Vincent van Ravesteijn
2010-11-10 19:13:48 UTC
Permalink
Post by Enrico Forestieri
Pavel,
Do you think it has a chance to make it into 2.0.0 ?
I think no, if we follow the rules.
I thought that the rule was to ask Pavel ;).

Vincent
Enrico Forestieri
2010-11-10 19:18:02 UTC
Permalink
Post by Vincent van Ravesteijn
Post by Enrico Forestieri
Pavel,
Do you think it has a chance to make it into 2.0.0 ?
I think no, if we follow the rules.
I thought that the rule was to ask Pavel ;).
http://www.mail-archive.com/lyx-***@lists.lyx.org/msg163211.html
--
Enrico
Vincent van Ravesteijn
2010-11-10 19:21:37 UTC
Permalink
Post by Vincent van Ravesteijn
I thought that the rule was to ask Pavel ;).
Development moved to the beta phase which basically means we will no
more include new features and focus on polishing the current ones.

"basically" leaves room for interpretation. Besides, you may also want
to see this as a bug. Having an application that opens files in tabs,
but suddenly opens a new application if you want to open a file through
the file manager.

Vincent
Enrico Forestieri
2010-11-10 19:24:21 UTC
Permalink
Post by Vincent van Ravesteijn
I thought that the rule was to ask Pavel ;).
Development moved to the beta phase which basically means we will
no more include new features and focus on polishing the current
ones.
"basically" leaves room for interpretation. Besides, you may also
want to see this as a bug. Having an application that opens files in
tabs, but suddenly opens a new application if you want to open a
file through the file manager.
Then, drag and drop the icon on the lyx instance you want.
--
Enrico
Pavel Sanda
2010-11-10 23:09:01 UTC
Permalink
Post by Enrico Forestieri
Do you think it has a chance to make it into 2.0.0 ?
I think no, if we follow the rules.
i would like to know whats going on behind this.
you dont like that
1. we push new features
2. this feature is evil
or 3. the implementation of this feature is not your taste?

my plan - and few times i wrote that - was that we do bugfixing and from time
to time some small feature can slip through the cracks - if we agree its safe.
the same as with releases before. somehow i didnt expected we start to nitpick
the defintion of new feature two hours after official entering of beta phase ;)

pavel
Pavel Sanda
2010-11-11 00:38:27 UTC
Permalink
Post by Pavel Sanda
Post by Enrico Forestieri
I think no, if we follow the rules.
i would like to know whats going on behind this.
you dont like that
1. we push new features
Yes, especially not when by the rules they would be "basically" forbidden.
thats misunderstanding. release announcement is public 'hello we are still
living' advertisement for _users_ around the globe where you dont have space
for explaining the subtleties of releasing stages.

for us - if you want some rules about releasing stages - take this
http://www.lyx.org/VersioningSystem
and this
http://www.mail-archive.com/lyx-***@lists.lyx.org/msg158367.html

in my understanding strict rules are needed when the last chance of normal
dicsussion is not possible and the environment starts turning into chaos.

even if i say strictly no features from now, you can always start playing with
the definition of bug vs feature. moreover some time i want to be open for few
particular things - like rc2rc conversion eg.
The same effect can be achieved with less code and without introducing
external dependencies.
i had similar feeling.
pavel
Enrico Forestieri
2010-11-11 04:08:03 UTC
Permalink
Post by Pavel Sanda
Post by Pavel Sanda
Post by Enrico Forestieri
I think no, if we follow the rules.
i would like to know whats going on behind this.
you dont like that
1. we push new features
Yes, especially not when by the rules they would be "basically" forbidden.
thats misunderstanding. release announcement is public 'hello we are still
living' advertisement for _users_ around the globe where you dont have space
for explaining the subtleties of releasing stages.
for us - if you want some rules about releasing stages - take this
http://www.lyx.org/VersioningSystem
A beta release (...) contains all major new functions of the next
stable release
Post by Pavel Sanda
and this
Beta - once we decide that all planned features are in and basically working
we move to beta. From this point the main focus of developers should
be cleaning the bugzilla from bugs with 2.0 target we get from users.
So some small features can happen, but its stopper for any refactoring
code "with some instability period" etc ;)
Post by Pavel Sanda
in my understanding strict rules are needed when the last chance of normal
dicsussion is not possible and the environment starts turning into chaos.
Of course, one can give any interpretation of the citations I reported
above, once a proper definition of "major" and "small" is given.
Due to this, I think that it means that the code can be "basically"
destabilized, provided that there's "consensus". Fine, good to know.
Post by Pavel Sanda
even if i say strictly no features from now, you can always start playing with
the definition of bug vs feature. moreover some time i want to be open for few
particular things - like rc2rc conversion eg.
Oh, I think that a good sophist could convince me that "major" means small
and "small" means major.
--
Enrico
Pavel Sanda
2010-11-11 14:41:41 UTC
Permalink
Post by Enrico Forestieri
Due to this, I think that it means that the code can be "basically"
destabilized, provided that there's "consensus". Fine, good to know.
yes.

do you know the immigration story of kurt goedel? before entering u.s.
he went closely throught the constitution to be prepared for the test.
however, he found that there are logical holes in the text which allows
to turn democracy into fascist dictatorship. his friends oskar morgenstern
and albert einstein who were helping him with immigration were not
able by no means to persuade him not to discuss such things on the exam :)

still he got it somehow...

pavel
Enrico Forestieri
2010-11-10 23:57:26 UTC
Permalink
Post by Pavel Sanda
Post by Enrico Forestieri
Do you think it has a chance to make it into 2.0.0 ?
I think no, if we follow the rules.
i would like to know whats going on behind this.
you dont like that
1. we push new features
Yes, especially not when by the rules they would be "basically" forbidden.
Post by Pavel Sanda
2. this feature is evil
Not evil, unnecessary.
Post by Pavel Sanda
or 3. the implementation of this feature is not your taste?
Bloat code introducing dependencies on external libraries for
unnecessary features. Yes, it does not meet my taste.
Post by Pavel Sanda
my plan - and few times i wrote that - was that we do bugfixing and from time
to time some small feature can slip through the cracks - if we agree its safe.
the same as with releases before. somehow i didnt expected we start to nitpick
the defintion of new feature two hours after official entering of beta phase ;)
The same effect can be achieved with less code and without introducing
external dependencies.
--
Enrico
Vincent van Ravesteijn
2010-11-10 17:21:52 UTC
Permalink
These two patches implement a single instance LyX.
Comments ?
Pavel,

Do you think it has a chance to make it into 2.0.0 ?

Vincent
Enrico Forestieri
2010-11-10 19:13:58 UTC
Permalink
- We then depend on QtNetwork.dll/lib
YA dependency. This is bad for a next to useless feature.
--
Enrico
Vincent van Ravesteijn
2010-11-10 19:17:11 UTC
Permalink
Post by Enrico Forestieri
- We then depend on QtNetwork.dll/lib
YA dependency. This is bad for a next to useless feature.
We can maybe rewrite it to use pipes. Or we can rewrite the piped code
to use QLocalSocket.

Vincent
Richard Heck
2010-11-10 20:10:07 UTC
Permalink
Post by Vincent van Ravesteijn
Post by Enrico Forestieri
- We then depend on QtNetwork.dll/lib
YA dependency. This is bad for a next to useless feature.
We can maybe rewrite it to use pipes. Or we can rewrite the piped
code to use QLocalSocket.
This does seem like a major dependency. If it could be removed, that
wouldn't be a bad thing.

The configure idea would help here, too.

rh
Enrico Forestieri
2010-11-10 20:49:46 UTC
Permalink
Post by Richard Heck
Post by Vincent van Ravesteijn
Post by Enrico Forestieri
- We then depend on QtNetwork.dll/lib
YA dependency. This is bad for a next to useless feature.
We can maybe rewrite it to use pipes. Or we can rewrite the piped
code to use QLocalSocket.
This does seem like a major dependency. If it could be removed, that
wouldn't be a bad thing.
The configure idea would help here, too.
There's already code that checks for an existing lyxpipe. If another
instance of lyx is connected to the other end, a message is printed
to that effect, otherwise it is a stale pipe (maybe a left over from
a previous crash) and is removed.

So, instead of printing a message to the console, the other instance
could be instructed to open a new document. Re-use of code, no new
dependencies on external libraries, everything under our control.
--
Enrico
Vincent van Ravesteijn
2010-11-11 01:57:48 UTC
Permalink
Post by Enrico Forestieri
There's already code that checks for an existing lyxpipe. If another
instance of lyx is connected to the other end, a message is printed
to that effect, otherwise it is a stale pipe (maybe a left over from
a previous crash) and is removed.
So, instead of printing a message to the console, the other instance
could be instructed to open a new document. Re-use of code, no new
dependencies on external libraries, everything under our control.
Enrico,

You're right and I'm not fighting. I just took a solution which was
'ready' and asked for comments. I had no intention to add
dependencies, to overdo your work or to add new features in the beta
phase or anything else without proper evaluation and discussion of the
to-be-added stuff.

The last thing I wanted to do is to spark a discussion between the
conservative people and the Qt-aholics (with all do respect).

I'd like you to guide me a bit in with respect to using the pipes
then. Detecting whether a pipe exists is indeed easy. However, I need
to add some public functions to the Server interface that relays to
LyXComm. Moreover, sending a new command over the pipe to the existing
application needs some of the client code.. right ?

If you can share your thoughts with me, I'd appreciate it.

Vincent
Enrico Forestieri
2010-11-12 14:47:03 UTC
Permalink
Here is another somewhat polished version.
So, should I commit this patch?
--
Enrico
Richard Heck
2010-11-12 15:49:28 UTC
Permalink
Post by Vincent van Ravesteijn
I'd like you to guide me a bit in with respect to using the pipes
then. Detecting whether a pipe exists is indeed easy. However, I need
to add some public functions to the Server interface that relays to
LyXComm. Moreover, sending a new command over the pipe to the existing
application needs some of the client code.. right ?
If you can share your thoughts with me, I'd appreciate it.
Please find attached a rough patch as proof of concept. It has to be
improved in many respects, but already does the job. I tested it on
both *nix and windows (with mingw) and it works for me. Simply setup
the lyxpipe and when you run lyx with a filename as argument, it
will be opened in already running instance.
Here is another somewhat polished version.
The only thing lacking here is the preference stuff, but someone else
could do that, if you wish.

Richard
Andre Poenitz
2010-11-10 23:14:11 UTC
Permalink
Post by Richard Heck
Post by Vincent van Ravesteijn
Post by Enrico Forestieri
- We then depend on QtNetwork.dll/lib
YA dependency. This is bad for a next to useless feature.
We can maybe rewrite it to use pipes. Or we can rewrite the piped
code to use QLocalSocket.
This does seem like a major dependency. If it could be removed, that
wouldn't be a bad thing.
Just for the record: QtNetwork is not even half the size of QtCore (an
eigth of QtGui), and I am not aware of any system or distribution that
would install one but not the other.

Andre'
Enrico Forestieri
2010-11-11 00:08:31 UTC
Permalink
Post by Andre Poenitz
Post by Richard Heck
Post by Vincent van Ravesteijn
Post by Enrico Forestieri
- We then depend on QtNetwork.dll/lib
YA dependency. This is bad for a next to useless feature.
We can maybe rewrite it to use pipes. Or we can rewrite the piped
code to use QLocalSocket.
This does seem like a major dependency. If it could be removed, that
wouldn't be a bad thing.
Just for the record: QtNetwork is not even half the size of QtCore (an
eigth of QtGui), and I am not aware of any system or distribution that
would install one but not the other.
A bug in an external library which mutilates a program is not less
serious even if its size was 1/1000 of QtCore. It is another external
risky dependency not justified by the benefit of the feature.
And the Qt files/pipes/sockets department is not exactly the strengther.
--
Enrico
Enrico Forestieri
2010-11-10 19:21:44 UTC
Permalink
Post by Vincent van Ravesteijn
Post by Enrico Forestieri
- We then depend on QtNetwork.dll/lib
YA dependency. This is bad for a next to useless feature.
We can maybe rewrite it to use pipes. Or we can rewrite the piped
code to use QLocalSocket.
Do whatever you like. I don't care anymore.
--
Enrico
Enrico Forestieri
2010-11-10 19:14:52 UTC
Permalink
http://www.gitorious.com/lyx/lyx/commit/b985f653c03ad9dbf77c9e3dadf9f6d3eeaba8ae
http://www.gitorious.com/lyx/lyx/commit/8edf37e21bfbbae23e87210b959ef9dfe5e8e81c
http://www.lyx.org/trac/ticket/2056
And why not attached here?
--
Enrico
Vincent van Ravesteijn
2010-11-10 19:16:16 UTC
Permalink
Post by Enrico Forestieri
http://www.gitorious.com/lyx/lyx/commit/b985f653c03ad9dbf77c9e3dadf9f6d3eeaba8ae
http://www.gitorious.com/lyx/lyx/commit/8edf37e21bfbbae23e87210b959ef9dfe5e8e81c
http://www.lyx.org/trac/ticket/2056
And why not attached here?
Google mail didn't want to upload the attachments.

Vincent
Pavel Sanda
2010-11-10 23:25:43 UTC
Permalink
- What kind of preference do we need ?
[ ] use single instance for all windows
i would vote for letting this off by default.
- Do we want to include the code for QtSingleApplication in our tree ?
- We then depend on QtNetwork.dll/lib and should be included in the installers.
on a first sight it looks like overkill to include 7 differently
licensed files for this issue. i hoped we could use pipes and small
independent binary for this or does it seem inappropriate?

pavel
Loading...