Application - Marc Bouvier

Join the team. This area is for people who want to participate in OpenMW's development in one way or another.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Application - Marc Bouvier

Post by Zini »

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.
User avatar
psi29a
Posts: 5356
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: Application - Marc Bouvier

Post by psi29a »

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.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Application - Marc Bouvier

Post by Zini »

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.
CramitDeFrog
Posts: 20
Joined: 18 Aug 2013, 00:29

Re: Application - Marc Bouvier

Post by CramitDeFrog »

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.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Application - Marc Bouvier

Post by Zini »

I do not know what you mean by this.
Making the startup window active is not trivial. Every desktop environment, including Windows and Mac, will require special code.
All you have to do is call

Code: Select all

mStartup.show();
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Application - Marc Bouvier

Post by Zini »

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.
CramitDeFrog
Posts: 20
Joined: 18 Aug 2013, 00:29

Re: Application - Marc Bouvier

Post by CramitDeFrog »

It's a little more than calling

Code: Select all

mStartup.show()
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.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Application - Marc Bouvier

Post by Zini »

Right.

Code: Select all

    show();
    raise();
    activateWindow();
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.
CramitDeFrog
Posts: 20
Joined: 18 Aug 2013, 00:29

Re: Application - Marc Bouvier

Post by CramitDeFrog »

I made the pull request.

I think

Code: Select all

show();
raise();
activateWindow();
is the correct way for QWidget's.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Application - Marc Bouvier

Post by Zini »

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.
Post Reply