mirrors/eiffel-org
1
0
Fork 0
mirror of https://github.com/EiffelSoftware/eiffel-org.git synced 2025-12-07 15:22:31 +01:00
Code Issues Packages Projects Releases Wiki Activity

Update wikipage How to build a concurrent graphical application: EiffelVision with SCOOP. (Signed-off-by:alexk).

Browse Source 
git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@1556 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
eiffel-org
2016-04-27 13:44:45 +00:00
parent f63793c40a
commit 227cf8fdab
1 changed files with 33 additions and 39 deletions
Download Patch File Download Diff File Expand all files Collapse all files

72
documentation/trunk/solutions/gui-building/eiffelvision-2/How-to-build-a-concurrent-graphical-application--EiffelVision-with-SCOOP.wiki
View File

@@ -1,39 +1,33 @@
[[Property:uuid|D1DDF411-5387-4A81-9A85-3EF8A2A4220D]]
[[Property:weight|0]]
[[Property:title|How to build a concurrent graphical application: EiffelVision with SCOOP]]
==How can I build a concurrent graphical in application in Eiffel?==
Eiffel has a great library for producing graphical applications: EiffelVision. Eiffel also has a powerful concurrency mechanism: SCOOP.
How do you make the two work together? This note gives you simple guidelines to ensure that the EiffelVision-SCOOP marriage is a harmonious and productive one.
The first question: why does the problem even exist? Let's go back to the pre-SCOOP days. Any graphical application has an "event loop", which keeps watching for graphical user events, such as a mouse click, and triggering the corresponding application responses, such as saving a file (if the user clicked ''OK'' on a ''File Save'' dialog). If you were using multithreading, the event loop would run in the main thread, also called the GUI (Graphical User Interface) thread.
Enter SCOOP. The old technique cannot work because a processor stuck in a loop cannot process any logged call! If you perform calls on a graphical widget, say the ''OK'' button, they will be logged right away, but they can only execute once the processor has exited its event loop. Not what you want.
So here is what you should do:
Since your application uses SCOOP, somewhere it creates a separate object. Let the creation instruction be
create s.make
where s is of a separate type (e.g. <eiffel>separate T</eiffel>).
In the <eiffel>make</eiffel> creation procedure, create an <eiffel>EV_APPLICATION</eiffel> object, using an instruction such as
create my_app
with <eiffel>my_app</eiffel> of type <eiffel>EV_APPLICATION</eiffel>.
Still in <eiffel>make</eiffel>, create all the GUI elements. They will all be in the same processor that created the <eiffel>EV_APPLICATION</eiffel> object.
Also in <eiffel>make</eiffel>, start the application, using
my_app.launch
In the pre-SCOOP world, launch would start the event loop. Here it only creates a separate object (of type <eiffel>EV_APPLICATION_HANDLER</eiffel>), which will run the event loop, forwarding events to the <eiffel>EV_APPLICATION</eiffel> object.
This is all the make procedure should do. Make sure it terminates with the preceding step. Otherwise, the event loop will never run!
Now you can start using EiffelVision as you are used to, by sending GUI requests to the <eiffel>EV_APPLICATION</eiffel> object:
* For requests coming from the same processor as s, just use the <eiffel>EV_APPLICATION</eiffel> object directly.
* For requests coming from another processor, you need access to that object; you can get it for example by through the feature <eiffel>ev_separate_application</eiffel> of class <eiffel>EV_SHARED_APPLICATION</eiffel>}.
That's all! Happy concurrent Eiffeling.
[[Property:uuid|D1DDF411-5387-4A81-9A85-3EF8A2A4220D]]
[[Property:weight|0]]
[[Property:title|How to build a concurrent graphical application: EiffelVision with SCOOP]]
==How can I build a concurrent graphical in application in Eiffel?==
Eiffel has a great library for producing graphical applications: EiffelVision. Eiffel also has a powerful concurrency mechanism: SCOOP.
How do you make the two work together? This note gives you simple guidelines to ensure that the EiffelVision-SCOOP marriage is a harmonious and productive one.
The first question: why does the problem even exist? Let's go back to the pre-SCOOP days. Any graphical application has an "event loop", which keeps watching for graphical user events, such as a mouse click, and triggering the corresponding application responses, such as saving a file (if the user clicked ''OK'' on a ''File Save'' dialog). If you were using multithreading, the event loop would run in the main thread, also called the GUI (Graphical User Interface) thread.
Enter SCOOP. The old technique cannot work because a processor stuck in a loop cannot process any logged call! If you perform calls on a graphical widget, say the ''OK'' button, they will be logged right away, but they can only execute once the processor has exited its event loop. Not what you want.
So here is what you should do:
In a creation procedure used to initialize GUI objects, create an <eiffel>EV_APPLICATION</eiffel> object, using an instruction such as
create my_app
with <eiffel>my_app</eiffel> of type <eiffel>EV_APPLICATION</eiffel>. (This may be a root creation procedure or a creation procedure of a separate object in case the root processor is going to be used for other operations.)
Then in the same creation procedure create all the GUI elements. They will all be in the same processor that created the <eiffel>EV_APPLICATION</eiffel> object.
After that start the application, using
my_app.launch
In the pre-SCOOP world, launch would start the event loop. Here it only creates a separate object (of type <eiffel>EV_APPLICATION_HANDLER</eiffel>), which will run the event loop, forwarding events to the <eiffel>EV_APPLICATION</eiffel> object.
This is all the creation procedure should do. Make sure it terminates with the preceding step. Otherwise, the event loop will never run!
Now you can start using EiffelVision as you are used to, by sending GUI requests to the <eiffel>EV_APPLICATION</eiffel> object:
* For requests coming from the same processor just use the <eiffel>EV_APPLICATION</eiffel> object directly.
* For requests coming from another processor, you need access to that object; you can get through the feature <eiffel>ev_separate_application</eiffel> of class <eiffel>EV_SHARED_APPLICATION</eiffel>.
That's all! Happy concurrent Eiffeling.