Created attachment 91392 [details] [review]
pre-alpha-patch for dualscreen presentations

Ok, I have been working on this for some time now. I have to warn you: This is my first C hacking in a while, and I am new to hacking GTK in C. 
So please don't get annoyed about my code quality ;-) I'm still learning and appreciate hints and tipps very much ... and I'm still motivated to get this feature working. 

Other words about the patch: 
 a) there is shell/ev-dualscreen.txt file for my notes

Some issues with the patch (there are a lot, and a lot are severe):
 b) window close doesn't work 
 (in dispose(GObject *obj), the following crashes):
       GtkWindow * win = GTK_WINDOW(obj);
       G_OBJECT_CLASS (win)->dispose (obj);
 c) navigating around in the document is quite slow (3 ev_views pointing to the same ev_document). Can this be improved by, e.g. loading the whole file in the cache or something? (just during the presentation)

I'm sure there are other questions I have, but I can't think of any atm (it's 04:26)

Interesting idea, thanks a lot for the patch Johannes. It requires some time to review it but I hope we'll be able to do it soon (in a few weeks I suppose)

Created attachment 91524 [details] [review]
alpha-patch for dualscreen presentations

Fixed the destroy problem ... window closes now ;-)

@everyone: Do me a favor if you want to review this patch, wait at least one week from now, there is a lot going on at the moment ... it looks like it's actually going to work.

Created attachment 92015 [details] [review]
Added automatic window placement

Warning, this should not be considered the final thing. 

There are lot's of (funny) comments in it, I left them in in hope they help for understanding (as the other parts of evince are not over-commented :-) ).
I added automatic window placement for 2 monitors.
Yes I was so evil to remove the "static" from ev_window_run_presentation and ev_window_stop_presentation. I am sure there are other ways you prefer.

It still misses the "add notes file"-feature. Also, the rendering is quite slow on my laptop, but it's bearable.

Created attachment 92069 [details] [review]
Working patch for dualscreen presentations (beta-1)

  - Rendering is quite slow. Can we improve that somehow? Maybe load the whole document in memory?
  - The documents always show the same page (number). Although I want that, I don't see _why_ it is happening.
  - Don't expect the best quality from this patch, it is my first. Coding standards and formatting may vary. Also, it might win the most-commented-file-in-evince award.
  - It works! This is so cool!! It would be awesome if that feature was added to evince. I know, the patch needs a lot of reviewing (e.g. memory leaks, dispose functions). 
  - I'm still not sure what's the right term to use in user interaction: dualscreen, multihead, ...

This patch is the basis for adding other features (maybe timer), so if anyone got time, please review it or test it.

A video of this patch in action can be found here:
http://www.gigasize.com/get.php/3195122783/try-2.ogg (16M)
I'm glad this is only available for the next 45 days (they say) ...

(23:47:43) nsh: Johannes42: btw, is there similar features in other presentation programs?
(23:48:01) nsh: like ooimpress and so on
(23:49:47) nsh: and/or probably acroread
(23:49:58) nsh: it would be nice to know how others work in this situation

another question, is it possible to detect dualhead monitor automatically?

> btw, is there similar features in other presentation programs?
I know that kpdf, acroread just provide fullscreen modes like evinces presentation mode. Whit they support is transitions (which I hate).
ooimpress and Microsoft Powerpoint don't have that either as far as I know. (Those are also not interesting for people (like me) doing presentations in latex).
The only application I know that does something comparable is this presentation app on Macs, Keynote. They essentially just show the current and the next slide on the screen. 

> another question, is it possible to detect dualhead monitor automatically?
Well if you mean detecting it in gtk, the patch already does it. from dualscreen.txt:
+About automatic window placement:
+	The general idea for window placement is that the user does it (move, set the 
+	first window to presentation mode).
+	
+	We do not provide any setup of dualscreen mode what so ever, the user has to
+	do this before (add second monitor in xorg.conf). 
+	
+	All we do is the following:
+	  - Leave the new window (dscwindow) on this screen, as we assume "this" 
+		screen is the default working screen, not the beamer/projector.
+	  If we have exactly 2 monitors also do the following:
+	  - throw the source window to "the other" screen.
+	  - maximize the source window & bring it to (normal) presentation mode
+	  - maximize the dscwindow.
+	
+	Also see gdk/multihead, GdkScreen, GdkDisplay in the gdk manual.
http://www.gtk.org/api/2.6/gdk/multihead.html

If you mean setting up X to support it, this can be quite delicate. I had 
aticonfig --initial=dual-head
do a part of the work.
One has something like this in xorg.conf:

Section "ServerLayout"
        Identifier     "Multihead layout"
        Screen      0  "aticonfig-Screen[0]" 0 0
        Screen         "aticonfig-Screen[1]" LeftOf "aticonfig-Screen[0]"
        InputDevice    "Keyboard0" "CoreKeyboard"
        InputDevice    "Mouse0" "AlwaysCore"
        Option      "Xinerama" "on"
        Option      "Clone" "on"
EndSection

Some things that came up in IRC:
 - We agreed to have not another menu entry. The behavior should be something like this: 
 - if we have 1 monitor -> normal presentation mode
 - if we have 2 monitors -> freaky presentation mode
 - It was suggested to use a normal evince window with thumbnails. Thumbnails don't resize and thus you won't see anything from >2m distance. We agreed on not doing that.
 - change C++ style comments // to /* */
 - less comments in the functions
 - move dualscreen.txt to NOTES

Adding randr 1.2 features will be another bug and the second generation of this feature. (like detection of adding a monitor and changing presentation mode accordingly). I'd like this to be started if this patch is in the repository.

Created attachment 92172 [details] [review]
Working patch for dualscreen presentations (beta-2)

While editing the code to address the issues above, I came about the following things:

 - There might me many comments, but (except for the TODOs) they mark design 
   decisions, and I think it is good practice to leave them in. 
   When maintaining or reviewing the code, someone or even I in a few years 
   might not understand why it is done this way and not another. Leaving those 
   comments in prohibits from missing some points of view.

 - I noticed that it is way better to leave the notes in the code than moving 
   them into NOTES or into ev-dualscreen.txt, because when editing the code, 
   those are probably updated, whereas in another file they get deprecated or 
   plain wrong. People who are interested in how and why we do what we do will 
   find it.
   
 - I adjusted some functions in ev-window. 
   run_presentation, stop_presentations made public
   update_view_size made public and changed second parameter as we don't really 
      need the window, but the scrolled_window. All calls were from
      ev_window_sizing_mode_changed_cb, I adjusted those.
   ev_window_get_screen_dpi made public and changed the parameter to parent 
      class GtkWindow. This is a generic function, and I need it too.
      I adjusted the calls.
   Check if this is ok for you. I did that to avoid code duplication and thus 
   duplicate bugs.

Created attachment 92173 [details] [review]
removed configure option

Sorry, the above file contains 
-GNOME_ICON_THEME_REQUIRED=2.17.1
+GNOME_ICON_THEME_REQUIRED=2.16.0
which I need for compile, I forgot to take it out. Here the rest again.

Created attachment 92511 [details] [review]
Preparation patch

Moving and modifying existing functions, adding get_num_monitors.
As discussed on IRC.
This patch was hand-edited, but it should apply cleanly against Rev 2581.

Created attachment 92512 [details] [review]
patch for dualscreen presentations (gamma)

Let's act like Microsoft and call this a cumulative patch. (includes the one above, because I couldn't separate them correctly). 

Some notes went to NOTES.
Some major TODOs were implemented (cool button bar added).

A few issues with preparation patch:

1. gtk-doc used different style for function description, please refer to examples
2. There were a lot of formatting issues
3. Style issues, for example it's better to check for wrong values first and return and then check for other cases. This simplify workflow, see updated get_num_screens for example.
4. We usually defer casts to the moment it's needed, it speedups things. That's why I've changed cast to scrolled window.
5. Check if you are adding duplicated includes
6. Don't add private includes to "public" headers
7. Don't use g_return_if_fail to check value if it can be NULL. This macros is only for debugging and can be even disabled in production code.

I'm going to commit this, please refer to update diff for details.

Ok, now we need updated main patch, I'll try to review it in the evening

Created attachment 92539 [details] [review]
patch for dualscreen presentations (gamma-2)

Patch against head, r2584

nsh, thank you very much for taking the time for reviewing and the detailed analysis. This really helps a lot.

Created attachment 92723 [details] [review]
Update

Heh, I've updated the patch slightly. But it's still not ready really. The widgets is too incomplete and for example toolbar below looks not so nice. 

Probably we need to consider using usual EvWindow as a controller. Thumbnails can be made bigger and this way we'll get more flexible system.

And, we'll need user documentation too, but it's a minor issue.

I think it's not a good idea to reuse thumbnails. Stand up, having your computer on the table and walk 2 meters away. The overview has to be 1/4 of the screen width to recognize something. Also, with thumbnails the size can not be varied. :-(

I don't think EvWindow is not such a good idea for a controller since it does lots of other things that would be in the way ... 

About the "toolbar below": You shouldn't look at that in a desktop user way (usual UI design). Think about you wanting to hold a presentation. While preparing the presentation (right monitor, right files) you want to use it, and it is there. But during the presentation you don't want it being in the way. Thus I made it on the bottom part, as space on the top and sides is critical (even as a collapsed expander). 

Can you explain "The widgets is too incomplete"? Beside that there should be forward and backward functionality. 

*** Bug 515637 has been marked as a duplicate of this bug. ***

Created attachment 128945 [details]
Screenshot of the idea

Similar Fedora bug:  https://bugzilla.redhat.com/show_bug.cgi?id=510089

*** Bug 591230 has been marked as a duplicate of this bug. ***

Is this patch still alive? Is there a current version that works with evince 2.24/2.26? This was just what I was looking for!

Hi,

I'm current maintainer of LaTeX Beamer class. Is it possible to make Evince use full-two-screen mode (instead of full-screen)? Beamer can prepare presentations for such use.

Now that presentation is another view widget (EvViewPresentation) it should be easier to implement.

Carlos, are you referring to the thing I asked for, or to patch at this bug?

I mean it's easier to implement dual screen presentations. What's exactly full-two-screen mode in beamer?

It's a "simple" name indicating that Evince would do full screen mode across both displays, instead of across just one it resides on.

An example of one slide of such presentation can be found in this archive: http://www.tug.org/pracjourn/2010-1/dohmen/dohmen.zip

That example pdf looks actually pretty hard to split into two logical parts? Or would you simply half it?

I would simply half it, assuming both monitors have same resolution. This stuff works on OS X with pdf-presenter [1], and on Linux with proprietary NVIDIA drivers which are able to trick X.Org apps into believing that there is only one very wide screen instead of two independant displays (which sucks in many ways).

If Evince implements this, I will do my best to make Beamer support asymetric case as well (e.g. when you have 1366x768 or 1280x800 on laptop and 1024x768 or 800x600 on projector).

[1] http://code.google.com/p/pdf-presenter/

Well I got this bug as part of my bachelor project. From looking at ev_presentation and gdk it should be possible to do it. Cause I don't think that creating one big window over two screens is ideal solution. Any hints or ideas?

Hi 255993. It is not only possible to do it, it has been done. The objections to my patches were based on maintainability and simplicity. In other words, I wrote a hack. 
I agree with you on the two-screens idea.
What you want to do is create one subclass of the main evince window to create the control window, and let it steer the main presentation window (for which you take the existing window, and set it to presentation mode).
Contact Nickolay (nsh) and/or Carlos -- they were very helpful to me -- on IRC.
I would like to see the feature implemented.

Hi 255993 !

Some people are asking about this feature. Are you finally working on this ? 

I hope so :)

(In reply to comment #25)
> Hi,
> 
> I'm current maintainer of LaTeX Beamer class. Is it possible to make Evince use
> full-two-screen mode (instead of full-screen)? Beamer can prepare presentations
> for such use.

Hi, it  is possible to do, although the main question is: is there any hint on the PDFs that Beamer generates that can be used to auto-detect that the PDF is a "full-two-screen presentation"? I don't like the idea of having to set an option to activate this mode, specially since there is no UI in Evince where you can add this (no toolbar in Presentation mode, for example). 

I guess I would like to see a combination of the original proposal + support for notes on the half-part of the page or support for notes on even pages of the pdf. This since the UI to set the options can be added to the "Laptop Window". Other Idea is to have an overlay window as in Totem or other Presenters out there that would provide the UI for this, but in order to do this beautifully, we probably need clutter.

I notice http://westhoffswelt.de/projects/pdf_presenter_console.html which seems to have similar features.  Is this of any use?

I'm working on it. You can get info from pdf metadata, look at pdfinfo. Problem is to recognise on which side the notes are. You can generate beamer pdfwith notes on top/left/right/bottom. Maybe I can guess it from document's proportions. Another problem is to split PDF into halfs so that it can be displayed on different screens. Or you can open same file twice and display it in such way, but that will eat memory. (I'm still learning gtk and stuff + a lot of exams lately.)

pdf_presenter_console seems interesting, I'll give it a look.

(In reply to comment #37)
> I'm working on it. 

Could you please explain your plans? I am actually starting to play with the idea of having two ev_windows (one controlling the other) so I don't want us to work on the same parts ;)

> You can get info from pdf metadata, look at pdfinfo. Problem
> is to recognise on which side the notes are. You can generate beamer pdfwith
> notes on top/left/right/bottom. Maybe I can guess it from document's
> proportions.
You can guess it, but this guess would be ackward, since it will work only for beamer generated files... We need to look for something better here. 

> Another problem is to split PDF into halfs so that it can be
> displayed on different screens. Or you can open same file twice and display it
> in such way, but that will eat memory. (I'm still learning gtk and stuff + a
> lot of exams lately.)

This part should not be difficult, you can modify EvViewPresentation to take a "viewport coords" GDKRectangle on creation, and then make EvViewPresentation Cache to only generate the corresponding part of each page. This way you could probably have two EvViewPresentation widgets without eating twice as much the memory.
 
  
> pdf_presenter_console seems interesting, I'll give it a look.

Sorry for commenting again, but I strongly believe that splitting a page in pdfs is not the right way to go. IMO, one should load one or two documents, which are displayed like pdf_presenter_console does (if two, the notes document is on the presenters control screen). The idea of mangling one page onto two screens, whose resolutions are unknown seems unnecessarily complex to me.

Most commonly, with latex/lyx pdf presentations, one just has one document (no notes), on a x-session with two monitors. If the latex beamer package can produce a annotated presentation, perhaps it would be wiser to make it output two documents (e.g. once called with a "notes-define", and once without).    

However, I am glad you both are working on this, and I encourage you should follow what you think is best or interesting! It would be good to see two approaches and two people being capable of discussing patches/options (especially since it is likely that at least one will give up). Best of luck!

P.S.: There is code on monitor-detection/switching in my (old) patch.

(In reply to comment #39)
> Sorry for commenting again, but I strongly believe that splitting a page in
> pdfs is not the right way to go. IMO, one should load one or two documents,
> which are displayed like pdf_presenter_console does (if two, the notes document
> is on the presenters control screen). The idea of mangling one page onto two
> screens, whose resolutions are unknown seems unnecessarily complex to me.
> 
> Most commonly, with latex/lyx pdf presentations, one just has one document (no
> notes), on a x-session with two monitors. If the latex beamer package can
> produce a annotated presentation, perhaps it would be wiser to make it output
> two documents (e.g. once called with a "notes-define", and once without).    
Beamer allows creating notes & presentation pdfs. But also we could use pdfinfo to get second page's positions trough using hyperref package. Btw probably all dualhead presentations will be with notes on left because of bugous pdf => pgfpages. The hyperlinks should not work in other setups.
> 
> However, I am glad you both are working on this, and I encourage you should
> follow what you think is best or interesting! It would be good to see two
> approaches and two people being capable of discussing patches/options
> (especially since it is likely that at least one will give up). Best of luck!
> 
> P.S.: There is code on monitor-detection/switching in my (old) patch.

I've read your code and I'd like to ask, wouldn't it be better to create new presentation window and don't switch the old one to the presentation? Right now I'm looking on correct way to store configs and how to create second window.

Hey 255993, good to hear from you! Stay active, and post what you're working on from time to time.

> > P.S.: There is code on monitor-detection/switching in my (old) patch.
> 
> I've read your code and I'd like to ask, wouldn't it be better to create new
> presentation window and don't switch the old one to the presentation? 

Either way is possible and fine. My train of thought was: what I add is a notes window, and the fullscreen presentation is what it was before. All I had to do with the original window was turn on the presentation mode. 

> Right now I'm looking on correct way to store configs and how to create second 
> window.
Also stay in touch with the maintainers / main developers (!= me), especially on these questions! Otherwise you might run into trouble getting your patch accepted on maintainability/style grounds.

o, sorry even more exams -> I'm slower than snail.
Finishing gtk-tutorial and evince code finaly makes
some sense to me. Here is rough translation of what
I'd like to code in ~2months.

Add edit option and widget
Menu -> Edit -> Presentation
Presentation:
+==========================================+
||DUALHEAD\|Timer\                         |
||         \------------------------------+|
||                                        ||
||                                        ||
||[ ] Use dealhead presentation if more   ||
||    than one monitor is availible       ||
||                                        ||
||   (o) Duplicate                        ||
||   ( ) Notes file:                      ||
||        ____________________[OPEN]      ||
||   ( ) Beamer with notes                ||
||       (o) right                        ||
||       ( ) left                         ||
||       ( ) top                          ||
||       ( ) bottom                       ||
||                                        ||
|+----------------------------------------+|
+------------------------------------------+

By default dualhead is off.

Default dualhead setting is Duplicate, where new
presentation window is created on non main display
and the old window stays same. Moving slides on
one window moves slides on the other one too.

If presenter wants to provide notes file to evince
he can choose Notes file option. Selected file is
saved per document into evince metadata.[evince 
already uses http://blogs.gnome.org/alexl/2009/06/24/data-about-data/]
Again presentation starts with creating window on non main
display. And control window opens notes.

Third option is locked by default and unlocks only
when Beamer is creator in pdf metadata. It will split
slides of pdf in half by using GDKRectangle. One half
will be open in control window and the other will
open in presentation window.

Control window in all dualhead settings can be switched
to presentation mode if F5 is pressed again.


Timer:
[TBD] Not part of this bug.

Evince doesn't have a preferences dialog by design, and we don't want to have one just for presentations. The dual head presentation mode should be the default one when multihead is detected.

What you write is good, 255993!
Duplicate can be default in multi-head; On the "control window" (the one on the display, not on the projector), a right-clicking option could be added to replace the content there with a notes file, and possibly more for the other options needed for beamer stuff.

Perhaps the secondary display (not the beamer) could show a (perhaps autohiding) toolbar with some options presented as check or combo boxes.

(In reply to comment #45)
> Perhaps the secondary display (not the beamer) could show a (perhaps
> autohiding) toolbar with some options presented as check or combo boxes.

If you look at the bottom left of http://bugzilla-attachments.gnome.org/attachment.cgi?id=128945 this is pretty much what I had.
One button for cycling the monitors used, one for loading the notes and one for quitting the presentation. There could be more there.

I'm now writing edit > presentation options applet but I got a bit stuck. I don't think it's a good idea to set document's dualhead metadata and then check metadata when starting presentation if dualhead is turned off. Should I stay with it or store this in ev_window?

(In reply to comment #47)
> I'm now writing edit > presentation options applet [...]

Thanks for working on this, but the evince maintainers do not think this is the right approach, as stated in comment 43.

ah I see, some mals from bugzilla didn't come. I didn't read web content, I'll try to chceck it from now on. Ok I'll drop the code (~200 lines don't hurt that much).

Yeah, don't add preference panes. It's quite easy to detect, using GdkDisplay and GdkScreen and such, whether the configuration is dual head or not. So you should just have code to detect multihead and use it accordingly by default.

placing the two windows if dualscreen:

+static void 
+ev_dscwindow_window_placement (EvDSCWindow * self)
+{
+	EvDSCWindowPrivate *priv = EV_DSCWINDOW_GET_PRIVATE (self);
+	
+	gint num_monitors = get_num_monitors (GTK_WINDOW (self));
+	if (num_monitors == 2) {
+		GtkWindow * presentation_window = GTK_WINDOW (priv->presentation_window);
+		GdkScreen * screen = gtk_window_get_screen (presentation_window);
+		
+		gint work_monitor = gdk_screen_get_monitor_at_window (screen, 
+			GTK_WIDGET (presentation_window)->window);
+		
+		gint presentation_monitor = (work_monitor + 1) % 2; 
+		
+		GdkRectangle coords;
+		gdk_screen_get_monitor_geometry (screen, presentation_monitor, 
+			&coords);
+		
+		gtk_window_move (presentation_window, coords.x, coords.y);
+		ev_window_run_presentation (priv->presentation_window);
+		priv->moveback_monitor = work_monitor;
+		
+		gtk_window_maximize (GTK_WINDOW (self));
+	}
+}


switching windows for primary/secondary monitors:

+	gint num_monitors = get_num_monitors (GTK_WINDOW (self));
+	
+	if (num_monitors == 2) {
+		GtkWindow * presentation_window = GTK_WINDOW (priv->presentation_window);
+		GdkScreen * screen = gtk_window_get_screen (presentation_window);
+		
+		gint monitor_1 = gdk_screen_get_monitor_at_window (screen, 
+			GTK_WIDGET (presentation_window)->window);
+		
+		gint monitor_2 = (monitor_1 + 1) % 2; 
+		
+		GdkRectangle coords;
+		gdk_screen_get_monitor_geometry (screen, monitor_2, &coords);
+		ev_window_stop_presentation (priv->presentation_window);
+		gtk_window_move (presentation_window, coords.x, coords.y);
+		ev_window_run_presentation (priv->presentation_window);
+		priv->moveback_monitor = monitor_1;
+		
+		gdk_screen_get_monitor_geometry (screen, monitor_1, &coords);
+		gtk_window_unmaximize (GTK_WINDOW (self));
+		gtk_window_move (GTK_WINDOW (self), coords.x, coords.y);
+		gtk_window_maximize (GTK_WINDOW (self));
+	}

*** Bug 644246 has been marked as a duplicate of this bug. ***

well there is ugly code, that for now somehow works, I'm pointing you to it so you might open issues/report back to me and annoy me with it. It seems to move faster when I get some feedback :)

https://github.com/xbezdick/evince-dualhead

Created attachment 187310 [details] [review]
patch for review

shell/ev-dualscreen > controll window used to controll presentation
shell/ev-presentation-timer > timer widget used to show progress in presentation and manage remaining time

Last patch is broken I already found too many bugs in it. I'm gonna fix that in ~week so if you are going to review this patch please have it in mind.

Review of attachment 187310 [details] [review]:

Marking as needs-work then while you are working on a new patch.

I am working on an alternate solution. I wrote beamer-control, a Python prototype that controls any number of evince instances simultaneously. It does this by using the AT-SPI interface.

I use beamer to create my presentations, and I generate two PDFs: slides and notes. As long as the slides and notes have the same number of pages, things work well.

See http://www.flyn.org/projects/beamer-control/.

(In reply to comment #57)
> I am working on an alternate solution. I wrote beamer-control, a Python
> prototype that controls any number of evince instances simultaneously. It does
> this by using the AT-SPI interface.
> 
> I use beamer to create my presentations, and I generate two PDFs: slides and
> notes. As long as the slides and notes have the same number of pages, things
> work well.
> 
> See http://www.flyn.org/projects/beamer-control/.

That's a great approach. Since it is apparently difficult to rehash evince into a different application, next to embedding a evince frame into a python window this is closest to a solution. The user just has to arrange the windows to her likings, then the slides proceed in parallel.

A clock that shows the time elapsed would be nice, but should be easy to do with pygtk. Well done!

(In reply to comment #57)

> I use beamer to create my presentations, and I generate two PDFs: slides and
> notes. As long as the slides and notes have the same number of pages, things
> work well.
> 
> See http://www.flyn.org/projects/beamer-control/.

It sounds interesting, but not really like a solution to this bug. 
Evince really needs to support a presentation mode itself, not have one imposed on it somehow from the outside.

*** Bug 515636 has been marked as a duplicate of this bug. ***

Hi, this bug is still open while someone has submitted a patch.

Ping

I am really looking forward to this evince presentation mode on dual screens.

Hello folks,

This would be a very nice and useful feature. I would appreciate to get in in evince, soon.

It would make life much easier when presenting PDFs created with LaTeX beamer.

Could someone give an update on how likley it is to get this into evince?

Best regards,
Joerg

Whoever volunteers to update the existing patch and makes it work. 
That could be you or anyone else, as usual in FOSS projects.

Well, then I'll hope that someone who finds this interesting too and has the abillity to implement it, will do it. Because I can't. :-(

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/evince/issues/40.