Xojo and Tiling Window Manager

I still can’t get Xojo maximum window size works in TWM (in this case I’m using i3-wm). The window is always launched in maximize state. The only working solution is to set the window as a modal (movable modal, modal dialog, etc). I’m also trying to mimic Xojo window by using Gtk. This Gtk code works as expected.

#include <gtk/gtk.h>

int main(int argc, char **argv)
{
    GtkWidget *app;

    gtk_init(&argc, &argv);

    app = gtk_window_new(GTK_WINDOW_TOPLEVEL);

    gtk_window_set_title(GTK_WINDOW(app), "Hello Gtk");
    gtk_window_set_resizable(GTK_WINDOW(app), false);
    gtk_window_set_gravity(GTK_WINDOW(app), GDK_GRAVITY_STATIC);
    gtk_widget_set_size_request(app, 600, 400);

    gtk_widget_show_all(app);
    g_signal_connect(app, "destroy", G_CALLBACK(gtk_main_quit), NULL);

    gtk_main();

    return 0;
}

This is window properties for both Xojo and Gtk.

_NET_WM_USER_TIME(CARDINAL) = 13288924
_NET_WM_STATE(ATOM) = 
_NET_WM_DESKTOP(CARDINAL) = 0
WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x1, 0x3e, 0x0, 0x0, 0x0
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: True
		Initial state is Normal State.
		window id # of group leader: 0x2c00001
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 46137349
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x2c00004
WM_CLIENT_LEADER(WINDOW): window id # 0x2c00001
_NET_WM_PID(CARDINAL) = 5965
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLIENT_MACHINE(STRING) = "pattisahusiwa"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified minimum size: 600 by 400
		program specified maximum size: 600 by 400
		window gravity: Static
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "DebugMyApplication", "DebugMyApplication"
WM_ICON_NAME(STRING) = "Untitled"
_NET_WM_ICON_NAME(UTF8_STRING) = "Untitled"
WM_NAME(STRING) = "Untitled"
_NET_WM_NAME(UTF8_STRING) = "Untitled"
_NET_WM_DESKTOP(CARDINAL) = 0
WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
I3_FLOATING_WINDOW(CARDINAL) = 1
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: True
		Initial state is Normal State.
		window id # of group leader: 0x2c00001
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 46137349
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x2c00004
WM_CLIENT_LEADER(WINDOW): window id # 0x2c00001
_NET_WM_PID(CARDINAL) = 5989
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLIENT_MACHINE(STRING) = "pattisahusiwa"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified minimum size: 600 by 400
		program specified maximum size: 600 by 400
		window gravity: Static
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "gtk-hello", "Gtk-hello"
WM_ICON_NAME(STRING) = "Hello Gtk"
_NET_WM_ICON_NAME(UTF8_STRING) = "Hello Gtk"
WM_NAME(STRING) = "Hello Gtk"
_NET_WM_NAME(UTF8_STRING) = "Hello Gtk"

The only main differences are I3_FLOATING_WINDOW(CARDINAL) = 1 and _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x1, 0x3e, 0x0, 0x0, 0x0. This behavior also affected Xojo license, options, about, and code completion windows. I need to force i3-wm to launch these windows in floating mode

for_window [class="Xojo" title="Licenses"] floating enable
for_window [class="Xojo" title="Options..."] floating enable
for_window [class="Xojo" title="About Xojo"] floating enable
for_window [class="Xojo" title="Untitled"] floating enable

Any idea?

Tiling window managers are not supported by the IDE
While some window types may work as floating there are others that won’t work as intended while using a tiling manager (autocomplete is good example)

Actually it really works on TWM and more faster than I’ve experienced before on Linux Mint or Ubuntu. It’s really usable on TWM environment.

By forcing autocomplete to be launched in floating window

for_window [class="Xojo" title="Untitled"] floating enable

I can make it to behave like on another window manager or desktop environment (see screenshot).

The only drawback is when there is another floating window opened while coding with Xojo. After autocomplete is closed, window focus is not return to the IDE instead of moved to the floating window.

In daily work, I’m coding with several IDE/text editor, this behavior only happened to Xojo IDE.

Oh, and I’ve a lot of apps made with Xojo that work well on both TWM and non TWM environment.

Did you force it to be modal ?
If so then its definitely not working as intended
That window should NOT be modal

Without forcing it to be a floating window, autocomplete will be useless. It will be opened in the maximized state in the different grid.

I’ve tried experimenting with 3 different language/compiler, Xojo; PureBasic; and C+GTK, only Xojo that failed to be launched in the defined maximum window size. I’ll try to consult to the i3-WM maintainers. Perhaps that’s a bug or an unimplemented feature.

Forcing it to be floating should not be a problem unless that also makes it modal in which case you may find “bugs” from having done this (which of course are not bugs since this is an unsupported configuration)

Yes, I know. Hence, I don’t open any floating window while coding with Xojo. Or, coding with Xojo on the different workspace to avoid this behavior.

Just curious why i3-wm ignore Xojo’s defined window size.

That I dont know
I dont use that sort of Window Manager and dont really have issues with performance of the IDE on Linux as long as the machine is suitably equipped - 8Gb Ram + a decent hardware accelerated GPU
Someone else (I’ll go find the posts) also mentioned they really found a sizeable boost in speed for the IDE when they put /tmp in memory

EDIT - the ideas discussed on this thread may be of use not JUST for the IDE bit in general
https://forum.xojo.com/33536-64-bit-linux-compilation-time

Just FYI
Some of the windows you also commented on are deliberately not modal
You can open them, set some things, go back to coding, etc
If they are modal that style of interaction doesn’t work as we intended it to

[quote=295285:@Norman Palardy]That I dont know
I dont use that sort of Window Manager and dont really have issues with performance of the IDE on Linux as long as the machine is suitably equipped - 8Gb Ram + a decent hardware accelerated GPU
Someone else (I’ll go find the posts) also mentioned they really found a sizeable boost in speed for the IDE when they put /tmp in memory

EDIT - the ideas discussed on this thread may be of use not JUST for the IDE bit in general
https://forum.xojo.com/33536-64-bit-linux-compilation-time[/quote]
I’m working on laptop with Intel i5-2410M 2.30GHz, 10GB DDR3, and 1 TB internal harddrive. The only drawback probably the VGA, it uses Intel HD 3000 Graphics.

[quote=295286:@Norman Palardy]Just FYI
Some of the windows you also commented on are deliberately not modal
You can open them, set some things, go back to coding, etc
If they are modal that style of interaction doesn’t work as we intended it to[/quote]

Yes, that’s what I’ve thought about. There are several unmerged pull request that add feature to handle the maximum/minimum size of window. I’ll stick with this configuration until they release that feature and see what happen then.

More than 8Gb is useful for Linux but the IDE is only a 32 bit process so more than that really doesn’t matter - except to the OS
An i5 is a tad slower than an i7 but not horribly so
How many cores has it got ? That may affect things as the IDE runs on one core.

A spinning HDD isn’t the best especially if its a slower laptop HD.
Is it at least a 7200 RPM drive - perhaps faster ?
How much do things swap ? Maybe that affects the IDE a lot ?

That graphics card is quite “low end” and so doesn’t help you

With 10Gb RAM you could probably put tmp in memory and get a very decent speed up for a small amount of work

In Linux, there are some problems with window size management, I think of Resized and Resizing Events that do not work as expected.

[quote=295291:@Norman Palardy]More than 8Gb is useful for Linux but the IDE is only a 32 bit process so more than that really doesn’t matter - except to the OS
An i5 is a tad slower than an i7 but not horribly so
How many cores has it got ? That may affect things as the IDE runs on one core.
[/quote]
four CPU core

$ nproc --all
4
$ sudo smartctl -i /dev/sda | grep rpm
Rotation Rate:      7200 rpm
$ free -h
              total        used        free      shared  buff/cache   available
Mem:           9.7G        865M        7.0G        105M        1.8G        8.4G
Swap:           14G          0B         14G

I really hardly see that the swap memory is used.

[quote=295291:@Norman Palardy]
That graphics card is quite “low end” and so doesn’t help you

With 10Gb RAM you could probably put tmp in memory and get a very decent speed up for a small amount of work[/quote]
I’ve tweaked Intel configuration to work better with Xorg. But, don’t know why this Xorg instance still needs intense IO access when draging and droping a control in Xojo IDE.

Xorg -nolisten tcp :0 vt1 -auth /tmp/serverauth.*

I do not have an issue with those events.

quote from i3 maintainers.

[quote]Either way, it appears to me that xojo hasn’t set the appropriate hints before mapping the window which would be a spec violation. Also, i3 will only float a window specifying the same minimum and maximum size during mapping, not later on.

I’d suggest you take this up with the xojo developers and have them look at the order in which they send X requests.[/quote]