DBus is the obvious candidate here, but we haven't decided on it. If it proves to be not feasible we will go for something else.
The general idea (for post-1.0) is to use the CS as a debugging tool for OpenMW content (scripts and other stuff), which means these two applications have to communicate in some way.
Application - Marc Bouvier
- psi29a
- Posts: 5356
- Joined: 29 Sep 2011, 10:13
- Location: Belgium
- Gitlab profile: https://gitlab.com/psi29a/
- Contact:
Re: Application - Marc Bouvier
If you want to avoid shared memory IPC, have you investigated Thrift or ZeroMQ? Maybe even Google Protocol Buffers?
http://en.wikipedia.org/wiki/Apache_Thrift
http://en.wikipedia.org/wiki/%C3%98MQ
http://en.wikipedia.org/wiki/Protocol_Buffers
Maybe overkill, but it should get the job done.
http://en.wikipedia.org/wiki/Apache_Thrift
http://en.wikipedia.org/wiki/%C3%98MQ
http://en.wikipedia.org/wiki/Protocol_Buffers
Maybe overkill, but it should get the job done.
Re: Application - Marc Bouvier
I don't think we have investigated anything yet. The whole thing is in a very early idea stage. What little connection between the editor and OpenCS we will have for 1.0 will be one way and can be done entirely through the command line interface without using any IPC.
-
- Posts: 20
- Joined: 18 Aug 2013, 00:29
Re: Application - Marc Bouvier
I have a working branch for Feature #881. I am using QLocalServer and QLocalSocket. DBus is too heavy to use to just add this feature. It will require another library and cross-platform code would be combersome. QSharedMemory was not a good idea, because there was no way for the existing application to know that a new instance is started without polling. This makes it hard to have the startup window reappear. QLocalServer can tell when a new connection is made. Also, it can be used as the IPC for the content debugging plan.
Making the startup window active is not trivial. Every desktop environment, including Windows and Mac, will require special code. Right now, the startup window appears, comes to the front, and will send a notification to the application icon (e.g. in Ubuntu/Unity the triangle in the launcher will turn blue and the icon will shake).
If this OK, then I will make a pull request.
Making the startup window active is not trivial. Every desktop environment, including Windows and Mac, will require special code. Right now, the startup window appears, comes to the front, and will send a notification to the application icon (e.g. in Ubuntu/Unity the triangle in the launcher will turn blue and the icon will shake).
If this OK, then I will make a pull request.
Re: Application - Marc Bouvier
I do not know what you mean by this.
All you have to do is callMaking the startup window active is not trivial. Every desktop environment, including Windows and Mac, will require special code.
Code: Select all
mStartup.show();
Re: Application - Marc Bouvier
btw. of cause you can send a pull request, when you think your code is ready or if you just want it to be reviewed. Pull requests are cheap. Use them liberally.
-
- Posts: 20
- Joined: 18 Aug 2013, 00:29
Re: Application - Marc Bouvier
It's a little more than calling because mStartup is hidden, but that is beside the point just a couple. I was afraid you were asking for the make mStartup active/current/working window (I have no idea what to call it lol). In other words, the window that doesn't have the dimmed title bar.
Cool. I will make one right now.
Code: Select all
mStartup.show()
Cool. I will make one right now.
Re: Application - Marc Bouvier
Right.
That's what we are currently using elsewhere. Actually not sure, if that is a smart thing to do, but we can as well role with it for now.
Code: Select all
show();
raise();
activateWindow();
-
- Posts: 20
- Joined: 18 Aug 2013, 00:29
Re: Application - Marc Bouvier
I made the pull request.
I think
is the correct way for QWidget's.
I think
Code: Select all
show();
raise();
activateWindow();
Re: Application - Marc Bouvier
That is not what I meant. The single widget approach we are currently using (and that makes the raise and activate part necessary) is kinda incompatible with the (multi-everything) design of the CS. But we can get to these kinds of details another time. Still way too little manpower on OpenCS and way to much work left to do, that we could afford to get bogged down in secondary details.