Dňa Tuesday 27 November 2007 23:06:13 Wim Dumon ste napísal:
On Nov 26, 2007 4:32 PM, Stanislav Visnovsky
wrote: Hi Wim!
Cool to see you here!
It's our pleasure to see that Wt is considered for Yast.
<snip>
The biggest issue I've faced was the fact that almost every functionality in the Wt classes went down to figuring out the session, and this info seems to be depend on the boost thread-local storage. So, I needed to be very careful in which thread I'm running, creating additional overhead.
See my other post, I think you should structure it differently so that you don't need any thread switching at all.
YaST has a base component library, which provides the main() function. This function evaluates the commandline arguments, picking client (typically YCP code) and server (typically UI).
You should accept that a single web daemon will be able to serve multiple yast sessions, and thus it is started in a way not specific to a particular user, but rather as a plain daemon.
The way you start yast from the command-line is on the same level as where a particular user surfs to the daemon and starts a new session. That will cause the 'create application' callback (argument of Wt::WRun) to get called, from which you have to return a WApplication object. If multiple users are surfing to the Yast website simultaneously, multiple Yast applications are running simultaneously, either as separate unix processes or within the same unix process, depending on your wt deployment options.
In threaded example, YCP code is started and when it first encounters UI call, it calls the UI component (*). The component then finally creates a real UI, starting a thread to handle events and redraws (call it UI thread). Every UI call from YCP synchronizes with the UI thread via 2 pipes implementing message passing, the real UI functionality is always evaluated in the UI thread.
I suggest you do something like this, since it only changes the bootstrap, and considers the YCP as a "worker" thread spawned from the Wt event loop:
- createApplication() [in the Wt thread], creates a YCP thread, and waits for a synchronization signal from the worker thread. - YCP thread triggers UI code which sets up synchronization pipes and signals the Wt thread - Wt thread creates the WApplication and (and anything else). From here on it should be the same story as the Qt UI, but instead of running app->exec() method, it returns the Application instance.
Bottom line: As Wt is an 'application server', it can cause multiple Yasts to be started (one per user surfing to the application server). We recommend to write your program in such a way as if the 'create application' callback that you specified as parameter of Wt::WRun() is the 'main()' function of what you would have written in a Qt application. The main task of main() in a Wt application is to call Wt::WRun().
What we've been trying to do is to integrate into already existing YaST structure and this seems to be not possible easily. I agree with your suggestion, however, this means a fundamental change how YaST deals with its UIs. OTOH, it might be a good idea to change it? ;-) Stano -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org