Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

frame extents synchronization #919

Closed
totaam opened this issue Jul 17, 2015 · 23 comments
Closed

frame extents synchronization #919

totaam opened this issue Jul 17, 2015 · 23 comments

Comments

@totaam
Copy link
Collaborator

totaam commented Jul 17, 2015

Issue migrated from trac ticket # 919

component: core | priority: major | resolution: fixed

2015-07-17 04:19:30: totaam created the issue

Split from #885 where most of the work was done in time for 0.15.
Related to #794 and #775.

The spec:

As of r9953, we expose all the frame attributes via xpra info, and they should also be set on the root window (as defaults) and on the window itself.

How to check:

  • on win32, the NativeGUI_info.exe should show the "window_frame" attributes (it would be useful to see how those values change with the DPI and screen size, if at all..) - the most relevant value being the "frame"
  • on OSX, r9954 adds a NativeGUI_info wrapper to the helpers (as per win32, DPI and screen size data could be useful)
  • with X11 clients (Linux), it is more difficult..
@totaam
Copy link
Collaborator Author

totaam commented Jul 17, 2015

2015-07-17 04:32:20: totaam changed owner from antoine to afarr

@totaam
Copy link
Collaborator Author

totaam commented Jul 17, 2015

2015-07-17 04:32:20: totaam commented

r9955 adds the "frame" debug logging flag which makes it much easier to figure out what is going on server side and with Linux clients. So now you can see the values used by X11 clients:

$ xpra attach -d frame
...
setup_frame_request_windows() window=0x3200056
...
get_window_frame_size(0, 0, 200, 200)=None
get_frame_extents(Xpra-FRAME_EXTENTS)=[0, 0, 37, 0]
get_window_frame_sizes()={'frame': [0, 0, 37, 0], 'offset': (0, 37)}
...
request_frame_extents(GLClientWindow(1 : None)) xid=0x32000d2
get_window_frame_size(37, 71, 499, 316)=None
get_frame_extents(antoine@desktop:~/projects/Xpra/trunk/src on desktop)=[0, 0, 37, 0]

And server side:

sync_frame: frame(0x600022)=None
sync_frame: setting _NET_FRAME_EXTENTS=(0, 0, 0, 0) on 0x600022
...
parse_hello_ui_window_settings: client window_frame_sizes={'frame': [0, 0, 37, 0], 'offset': [0, 37]}
set_default_frame_extents([0, 0, 37, 0])
sync_frame: frame(0x600022)=None
sync_frame: setting _NET_FRAME_EXTENTS=[0, 0, 37, 0] on 0x600022
sync_frame: frame(0x600022)=(0, 0, 37, 0)
sync_frame: setting _NET_FRAME_EXTENTS=(0, 0, 37, 0) on 0x600022

Note: we initially set the frame extents to (0, 0, 0, 0) before the first client connects - that's because we have to set something... and we have no idea what values the client will be using, I guess we could provide a global server-side default somewhere. No big deal I think.

We can check the "default" frame using:

$ xprop -root | grep -i DEFAULT_NET_FRAME
DEFAULT_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 37, 0

We can check individual window frames with:

  • xpra info:
$ xpra info | egrep "\.title=|\.frame="
client.window.frame-sizes.frame=(0, 0, 37, 0)
window[1].frame=(0, 0, 37, 0)
window[1].title=antoine@desktop:~/projects/Xpra/trunk/src

(which also logs the client supplied frame sizes)

  • or using xprop to read the X11 property:
$ xprop -id $WINDOWID | grep FRAME
_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 37, 0

You can get the WINDOWID from the log messages (ie: "0x600022" above) or from:

$ xpra info | egrep "\.title=|xid="
window[1].title=antoine@desktop:~/projects/Xpra/trunk/src
window[1].xid=0x600022

@totaam
Copy link
Collaborator Author

totaam commented Sep 17, 2015

2015-09-17 16:46:10: antoine commented

@afarr: how to test:
run NativeGUI_info.exe on win32 and NativeGUI_info on osx with different DPI and screen settings to see if the values change, if they do then please re-assign to me so that I can ensure we update the values when the screen configuration changes. (only just thought about this possibility)
Having a record of those values will also be useful.
Feel free to also verify that the windows have the correct attributes set as per comment:1.

@totaam
Copy link
Collaborator Author

totaam commented Oct 14, 2015

2015-10-14 02:11:53: afarr commented

Testing with windows 8.1 0.16.0 r10783 (and your osx 0.16.0 r10828) clients against fedora 21 0.16.0 r10786.

Running NativeGUI_info.exe with default settings for a 4K display and a laughably low resolution second monitor -


2015-10-13 15:31:00,392 xpra gtk2 client version 0.16.0-[r10783](../commit/722dc1a9c376b70cbc5ba00b2974b9a905c4f0c5)
2015-10-13 15:31:01,127 OpenGL_accelerate module loaded
2015-10-13 15:31:01,220  detected keyboard: layout=us
2015-10-13 15:31:01,237  desktop size is 5120x2160 with 1 screen(s):
2015-10-13 15:31:01,239   Default (1354x571 mm - DPI: 96x96) workarea: 5120x2120
2015-10-13 15:31:01,240     DISPLAY1 3840x2160 at 1280x0 (621x341 mm - DPI: 157x160) workarea: 5120x2120
2015-10-13 15:31:01,240     DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 5120x2120
2015-10-13 15:31:01,482 server: Linux Fedora 21 Twenty One, Xpra version 0.16.0-[r10786](../commit/0a91bd9b65266c567e71e600180662098c0752d1)

I get values that look expected:

C:\Program Files (x86)\Xpra>NativeGUI_info.exe
* antialias.contrast               : 1200
* antialias.enabled                : True
* antialias.hinting                : True
* antialias.orientation            : RGB
* antialias.type                   : ClearType
* desktop_names                    : []
* desktops                         : 1
* double_click.distance            : (4, 4)
* double_click.time                : 500
* dpi                              : 96
* dpi.x                            : 96
* dpi.y                            : 96
* fixed_cursor_size                : (32, 32)
* icon_size                        : 16
* native_notifiers                 : ['Win32_Notifier']
* native_system_trays              : ['Win32Tray']
* native_tray_menu_helpers         : []
* native_trays                     : ['Win32Tray']
* system_bell                      : system_bell
* vertical-refresh                 : 29
* window_frame.border              : 1
* window_frame.caption             : 23
* window_frame.fixed               : (3, 3)
* window_frame.frame               : (8, 8, 31, 8)
* window_frame.menu-bar            : 20
* window_frame.minimum             : (140, 39)
* window_frame.normal              : (8, 8)
* window_frame.offset              : (8, 31)
* workarea                         : (0, 0, 5120, 2120)
* workareas                        : [(0, 0, 3840, 2120), (0, 0, 1280, 680)]

I then used control panel slider to set to a resolution of 1920x1080 on the main display, which was immediately picked up and output client side:

2015-10-13 15:37:25,634 sending updated screen size to server: 3200x1080 with 1 screens
2015-10-13 15:37:25,638   Default (846x285 mm - DPI: 96x96) workarea: 3200x1040
2015-10-13 15:37:25,641     DISPLAY1 1920x1080 at 1280x0 (621x341 mm - DPI: 78x80) workarea: 3200x1040
2015-10-13 15:37:25,644     DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 3200x1040
2015-10-13 15:37:25,645 screen size change: will reinit the windows

After which NativeGUI_info.exe again outputs what looks like it should be expected:

changing display to 1920x1080:

C:\Program Files (x86)\Xpra>NativeGUI_info.exe
* antialias.contrast               : 1200
* antialias.enabled                : True
* antialias.hinting                : True
* antialias.orientation            : RGB
* antialias.type                   : ClearType
* desktop_names                    : []
* desktops                         : 1
* double_click.distance            : (4, 4)
* double_click.time                : 500
* dpi                              : 96
* dpi.x                            : 96
* dpi.y                            : 96
* fixed_cursor_size                : (32, 32)
* icon_size                        : 16
* native_notifiers                 : ['Win32_Notifier']
* native_system_trays              : ['Win32Tray']
* native_tray_menu_helpers         : []
* native_trays                     : ['Win32Tray']
* system_bell                      : system_bell
* vertical-refresh                 : 29
* window_frame.border              : 1
* window_frame.caption             : 23
* window_frame.fixed               : (3, 3)
* window_frame.frame               : (8, 8, 31, 8)
* window_frame.menu-bar            : 20
* window_frame.minimum             : (140, 39)
* window_frame.normal              : (8, 8)
* window_frame.offset              : (8, 31)
* workarea                         : (0, 0, 3200, 1040)
* workareas                        : [(0, 0, 1920, 1040), (0, 0, 1280, 680)]

When I run NativeGUI_info on the OSX client, however... it's not so happy:

Schadenfreude:Helpers Schadenfreude$ ./NativeGUI_info
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/osx/gtk/inst/lib/python2.7/site-packages/xpra/platform/gui.py", line 212, in main
ImportError: No module named x11.bindings
  • When I run with windows with -d frame I get more of what looks expected.

Client-side:

2015-10-13 15:57:31,821 get_window_frame_sizes()={'caption': 23, 'minimum': (140, 39), 'menu-bar': 20, 'normal': (8, 8), 'frame': (8, 8, 31, 8), 'fixed': (3, 3), 'bo
rder': 1, 'offset': (8, 31)}
2015-10-13 15:57:32,055 server: Linux Fedora 21 Twenty One, Xpra version 0.16.0-[r10786](../commit/0a91bd9b65266c567e71e600180662098c0752d1)
2015-10-13 15:57:32,071 Attached to tcp:10.0.32.136:2200 (press Control-C to detach)

2015-10-13 15:57:32,101 get_window_frame_sizes()={'caption': 23, 'minimum': (140, 39), 'menu-bar': 20, 'normal': (8, 8), 'frame': (8, 8, 31, 8), 'fixed': (3, 3), 'bo
rder': 1, 'offset': (8, 31)}
2015-10-13 15:57:32,117 get_window_frame_sizes()={'caption': 23, 'minimum': (140, 39), 'menu-bar': 20, 'normal': (8, 8), 'frame': (8, 8, 31, 8), 'fixed': (3, 3), 'bo
rder': 1, 'offset': (8, 31)}
2015-10-13 15:57:32,117 get_window_frame_sizes()={'caption': 23, 'minimum': (140, 39), 'menu-bar': 20, 'normal': (8, 8), 'frame': (8, 8, 31, 8), 'fixed': (3, 3), 'bo
rder': 1, 'offset': (8, 31)}
2015-10-13 15:57:32,132 get_window_frame_sizes()={'caption': 23, 'minimum': (140, 39), 'menu-bar': 20, 'normal': (8, 8), 'frame': (8, 8, 31, 8), 'fixed': (3, 3), 'bo
rder': 1, 'offset': (8, 31)}
2015-10-13 15:57:32,148 get_window_frame_size(1592, 312, 499, 316)=None
2015-10-13 15:57:32,148 get_window_frame_sizes()={'caption': 23, 'minimum': (140, 39), 'menu-bar': 20, 'normal': (8, 8), 'frame': (8, 8, 31, 8), 'fixed': (3, 3), 'bo
rder': 1, 'offset': (8, 31)}
2015-10-13 15:57:32,148 get_window_frame_size(1618, 338, 499, 316)=None
2015-10-13 15:57:32,148 get_window_frame_sizes()={'caption': 23, 'minimum': (140, 39), 'menu-bar': 20, 'normal': (8, 8), 'frame': (8, 8, 31, 8), 'fixed': (3, 3), 'bo
rder': 1, 'offset': (8, 31)}

And server-side:

2015-10-13 15:57:52,145 parse_hello_ui_window_settings: client window_frame_sizes={'menu-bar': 20, 'normal': [8, 8], 'frame': [8, 8, 31, 8],    'caption': 23, 'minimum': [140, 39], 'offset': [8, 31], 'fixed': [3, 3], 'border': 1}
2015-10-13 15:57:52,145 set_default_frame_extents([8, 8, 31, 8])
2015-10-13 15:57:52,146 sync_frame: frame(0x600022)=None
2015-10-13 15:57:52,146 sync_frame: setting _NET_FRAME_EXTENTS=[8, 8, 31, 8] on 0x600022
2015-10-13 15:57:52,147 sync_frame: frame(0x800022)=None
2015-10-13 15:57:52,147 sync_frame: setting _NET_FRAME_EXTENTS=[8, 8, 31, 8] on 0x800022
2015-10-13 15:57:52,183 DPI set to 96 x 96
2015-10-13 15:57:52,261 sync_frame: frame(0x600022)=(8, 8, 31, 8)
2015-10-13 15:57:52,261 sync_frame: setting _NET_FRAME_EXTENTS=(8, 8, 31, 8) on 0x600022
2015-10-13 15:57:52,263 sync_frame: frame(0x800022)=(8, 8, 31, 8)
2015-10-13 15:57:52,264 sync_frame: setting _NET_FRAME_EXTENTS=(8, 8, 31, 8) on 0x800022

Oddly, I found that there were no changes as I moved windows around, re-sized, or used xterms to spawn other applications - perhaps I'm just misinterpreting the use of FRAME in this context though (perhaps this is just outputting initial frame sizes and locations?).

Likewise, when I used xpra info to sift for frames and titles, I got the same output no matter what I did in the way of moving or re-sizing the windows (even if I re-sized the chromium window drastically to window[3].size=(2786, 2081):

[tlaloc@jimador ~]$ xpra info :13 | egrep "\.title=|\.frame="
client.window.frame-sizes.frame=(8, 8, 31, 8)
window[1].frame=(8, 8, 31, 8)
window[1].title=tlaloc@jimador:/usr/bin
window[2].frame=(8, 8, 31, 8)
window[2].title=tlaloc@jimador:~
window[3].frame=(8, 8, 31, 8)
window[3].title=New Tab - Chromium

I also got the same xprop -id values, whatever I did:

[tlaloc@jimador ~]$ xprop -id 0xc00001 -display :13 | grep FRAME
_NET_FRAME_EXTENTS(CARDINAL) = 8, 8, 31, 8

And, disconnecting then re-starting the server, I get nothing from xprop -root:

[tlaloc@jimador ~]$ xprop -root -display :13 | grep -i DEFAULT_NET_FRAME
[tlaloc@jimador ~]$

After connecting, and after then disconnecting a client, I get the same DEFAULT_NET_FRAME_EXTENTS(CARDINAL) = 8, 8, 31, 8 whatever I do.

@totaam
Copy link
Collaborator Author

totaam commented Oct 14, 2015

2015-10-14 02:20:11: afarr changed owner from afarr to antoine

@totaam
Copy link
Collaborator Author

totaam commented Oct 14, 2015

2015-10-14 02:20:11: afarr commented

One last detail - connecting with -d frame with my osx client is producing slightly different output (probably reflective of the initial positioning and default sizes of the frames?):

Client connection display info output:

2015-10-13 18:13:31,467  desktop size is 2960x2490 with 1 screen(s):
2015-10-13 18:13:31,468   schadenfreude.local (1044x878 mm - DPI: 72x72)
2015-10-13 18:13:31,468     monitor 1 1680x1050 at 1280x1440 (592x370 mm - DPI: 72x72)
2015-10-13 18:13:31,468     monitor 2 2560x1440 (903x508 mm - DPI: 72x72)

Client-side log output:

2015-10-13 18:13:31,481 get_window_frame_sizes()={'frame': (0, 0, 22, 0), 'offset': (0, 22)}
2015-10-13 18:13:31,574 server: Linux Fedora 21 Twenty One, Xpra version 0.16.0-[r10786](../commit/0a91bd9b65266c567e71e600180662098c0752d1)
2015-10-13 18:13:31,586 Attached to tcp:10.0.32.136:2200 (press Control-C to detach)

2015-10-13 18:13:31,641 get_window_frame_size(0, 22, 499, 316)=None
2015-10-13 18:13:31,641 get_window_frame_sizes()={'frame': (0, 0, 22, 0), 'offset': (0, 22)}
2015-10-13 18:13:31,642 get_window_frame_size(0, 22, 499, 316)=None
2015-10-13 18:13:31,642 get_window_frame_sizes()={'frame': (0, 0, 22, 0), 'offset': (0, 22)}

Server-side:

2015-10-13 18:13:22,282 sync_frame: frame(0x800022)=None
2015-10-13 18:13:22,283 sync_frame: setting _NET_FRAME_EXTENTS=(0, 0, 0, 0) on 0x800022
2015-10-13 18:13:22,288 sync_frame: frame(0x600022)=None
2015-10-13 18:13:22,288 sync_frame: setting _NET_FRAME_EXTENTS=(0, 0, 0, 0) on 0x600022

...

2015-10-13 18:13:32,250 parse_hello_ui_window_settings: client window_frame_sizes={'frame': [0, 0, 22, 0], 'offset': [0, 22]}
2015-10-13 18:13:32,250 set_default_frame_extents([0, 0, 22, 0])
2015-10-13 18:13:32,251 sync_frame: frame(0x800022)=None
2015-10-13 18:13:32,251 sync_frame: setting _NET_FRAME_EXTENTS=[0, 0, 22, 0] on 0x800022
2015-10-13 18:13:32,251 sync_frame: frame(0x600022)=None
2015-10-13 18:13:32,252 sync_frame: setting _NET_FRAME_EXTENTS=[0, 0, 22, 0] on 0x600022
2015-10-13 18:13:32,304 DPI set to 72 x 72
2015-10-13 18:13:32,337 sync_frame: frame(0x800022)=(0, 0, 22, 0)
2015-10-13 18:13:32,337 sync_frame: setting _NET_FRAME_EXTENTS=(0, 0, 22, 0) on 0x800022
2015-10-13 18:13:32,339 sync_frame: frame(0x600022)=(0, 0, 22, 0)
2015-10-13 18:13:32,339 sync_frame: setting _NET_FRAME_EXTENTS=(0, 0, 22, 0) on 0x600022

On the whole though, except for that OSX traceback... it looks like it's outputting what I'm expecting, so I'll pass it back to you.

@totaam
Copy link
Collaborator Author

totaam commented Oct 14, 2015

2015-10-14 06:01:50: antoine changed owner from antoine to afarr

@totaam
Copy link
Collaborator Author

totaam commented Oct 14, 2015

2015-10-14 06:01:50: antoine commented

Interesting to see that MS Windows uses the same window frame size with high and low DPI displays.
Does the value change on OSX when you change resolutions / DPI? I am also getting (0, 0, 22, 0) in my OSX 10.5.8 build VM.
Thanks for the OSX stacktrace, this is fixed in r10833.
[[BR]]

Oddly, I found that there were no changes as I moved windows around, re-sized, or used xterms to spawn other applications - perhaps I'm just misinterpreting the use of FRAME in this context though (perhaps this is just outputting initial frame sizes and locations?).
[[BR]]
The frame size is the the width and height of the frame around our window: aka the "decorations". This includes the height of the title bar (if present) and window borders.
This size should be the same whether the windows are small or big. Moving the window does not usually change the size of those decorations...
It may change with DPI, and if we were "per monitor DPI aware" it may change when moving to a monitor with a different DPI setting (Windows 8.1 and later only) - TBC.

[[BR]]

See #976#comment:15O :

@totaam
Copy link
Collaborator Author

totaam commented Oct 23, 2015

2015-10-23 23:22:25: afarr changed owner from afarr to antoine

@totaam
Copy link
Collaborator Author

totaam commented Oct 23, 2015

2015-10-23 23:22:25: afarr commented

With OSX client 0.16.0 r10972 (your repo) installed, running NativeGui_info, I'm no longer getting tracebacks, but I'm not seeing any difference in results when I use System Preferences to change screen resolutions... in fact it's still not seeming to grab any info for workarea.

With a variety of screen resolution settings, changing none, or one, or both monitor resolutions... I get this same result every time:

Schadenfreude:Helpers Schadenfreude$ ./NativeGUI_info 
* cursor_size                      : -1
* desktop_names                    : []
* desktops                         : 1
* double_click.distance            : (-1, -1)
* double_click.time                : 480
* dpi.x                            : -1
* dpi.y                            : -1
* fixed_cursor_size                : (-1, -1)
* icon_size                        : 16
* native_notifiers                 : []
* native_system_trays              : []
* native_tray_menu_helpers         : ['getOSXMenuHelper']
* native_trays                     : ['OSXTray']
* system_bell                      : system_bell
* vertical-refresh                 : -1
* window_frame.frame               : (0, 0, 22, 0)
* window_frame.offset              : (0, 22)
* workarea                         : 
* workareas                        : []

Connecting with -d frame seems to give same values as above, as well as a lot of tracebacks recorded in #1010.

Since I assume the workarea(s) shouldn't be blank, I'll assign back to you to look at.

@totaam
Copy link
Collaborator Author

totaam commented Oct 24, 2015

2015-10-24 03:53:27: antoine changed status from new to assigned

@totaam
Copy link
Collaborator Author

totaam commented Oct 24, 2015

2015-10-24 03:53:27: antoine commented

The workarea detection does not exist in OSX, so we don't populate it.
Anyway, this would belong in a different ticket - this ticket is only about frame extents.

I will need a Windows >= 8.1 system to fix the "dpi awareness" code.

@totaam
Copy link
Collaborator Author

totaam commented Nov 8, 2015

2015-11-08 15:37:27: antoine changed status from assigned to new

@totaam
Copy link
Collaborator Author

totaam commented Nov 8, 2015

2015-11-08 15:37:27: antoine changed owner from antoine to afarr

@totaam
Copy link
Collaborator Author

totaam commented Nov 8, 2015

2015-11-08 15:37:27: antoine commented

Note: r11151 fixes windows 8.1 onwards "DPI awareness".

@totaam
Copy link
Collaborator Author

totaam commented Nov 13, 2015

2015-11-13 04:20:09: antoine commented

Some of the data in this ticket may not be correct (done without logging out and logging back in with win32).

The correct and up to date information on DPI is now being moved to [/trac/wiki/DPI]

@totaam
Copy link
Collaborator Author

totaam commented Dec 9, 2015

2015-12-09 01:56:40: afarr commented

trac/wiki/DPI/Data now has the NativeGUI_info.exe window_frame data for windows 7 and 8.1 (with a small variety of displays).

"DPI awareness", however, doesn't seem to be changing any output (though, XPRA_DPI_AWARENESS=1 or =2 probably isn't being caught by NativeGUI_info.exe, and window_frame stuff isn't captured with /usr/lib64/python2.7/site-packages/xpra/platform/gui.py, so I'm not sure where else to look for the effects).

I'll do another run through the osx, but I don't think the frame info was changing at all last time I went through.

@totaam
Copy link
Collaborator Author

totaam commented Jan 11, 2016

2016-01-11 21:16:05: afarr commented

Went through Frame Sizes listed with NativeGUI_info on OSX — and discovered that it is the same no matter what sort of monitor is used, how many monitors, what the scaling is set to (even logged out to test in case I was missing fine print there).

Tested with 0.16.1 11604 osx client, osx 10.9.5 and 10.10.4.

Added the limited data gleaned to trac/wiki/DPI.

I think this ticket is ready to be re-closed - passing it to you Antoine to see if there's anything I've missed.

@totaam
Copy link
Collaborator Author

totaam commented Jan 11, 2016

2016-01-11 21:16:42: afarr changed owner from afarr to antoine

@totaam
Copy link
Collaborator Author

totaam commented Jan 12, 2016

2016-01-12 01:49:39: antoine changed status from new to closed

@totaam
Copy link
Collaborator Author

totaam commented Jan 12, 2016

2016-01-12 01:49:39: antoine set resolution to fixed

@totaam
Copy link
Collaborator Author

totaam commented Jan 12, 2016

2016-01-12 01:49:39: antoine commented

See also: bug in compiz #1279

@totaam totaam closed this as completed Jan 12, 2016
@totaam
Copy link
Collaborator Author

totaam commented Oct 3, 2018

2018-10-03 07:40:23: antoine commented

As of r20594, we can disable frame extents with:

XPRA_FRAME_EXTENTS=0 xpra ...

@totaam totaam added the v0.15.x label Jan 22, 2021
This was referenced Jan 22, 2021
Closed
Closed
Closed
Closed
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@totaam