Freefilesync window frame flashes briefly upon start

[bselu]

On my Linux machine I have cronjob running this command every minute:

/usr/bin/freefilesync /home/elu/data.ffs_batch

It works fine, but there is one catch. Although started in batch mode (i.e. no GUI is displayed) I see the frame of the freefilesync GUI window flashing briefly for like 50ms before it disappears again and the task bar icon appears as expected.

Is there a way to prevent that window frame flashing? It is quite annoying if you have a cronjob running this command every minute. It syncs a file system mounted via SMB, so I need to poll.

Is there anything I can do about it?

[xCSxXenon]

On Windows, you can use "Start /MIN xxxx" to run an executable minimized. If there is something similar for Linux, this should avoid any visuals from appearing

[Zenju]

You're likely missing the "run minimized" option:
https://freefilesync.org/manual.php?topic=schedule-batch-jobs

[xCSxXenon]

You're likely missing the "run minimized" option:
https://freefilesync.org/manual.php?topic=schedule-batch-jobs

I considered this but didn't suggest it yet because my GUI stays open if I don't check that box. Good quick suggestion though

[bselu]

Thanks for your replies.

The "run minized" option is checked:
<ProcessDialog Minimized="true" AutoClose="true">

The option is working, the application gets immediately minimized but only after a short flashing of the window border.

I tried finding something like "Start /MIN xxxx" for Linux, but all options I found only fiddle with the window once it's already open (e.g. like xdotool). There doesn't seem to be a general way to launch X applications in a minimized fashion.

However, I could get rid of the flashing main window by running freefilesync on a different X DISPLAY (created via xvfb). Unfortunately in this case the minimized icon is also not visible on my primary screen and (what kills this option entirely for me) any error popup will also be displayed on that other screen, so I cannot react to sync errors.

I just checked the GTK docs, there is a Window.minimize() function:
https://gjs-docs.gnome.org/gtk40~4.0/gtk.window#method-minimize

But I couldn't find a call to it in the freefilesync sources. So I assume it's currently done in a different way. But I lack the time to do more investigation myself. Could somebody help me here?

[Zenju]

Are you using the offical FFS binary (based on GTK2) or some third-party build (based on GTK3)?

[bselu]

Aha!! Thanks for that question. I was using the official Ubuntu 24.04 build. As can be seen on https://packages.ubuntu.com/noble/freefilesync it is linked against GTK3.

I just tried the official build from your site and this does NOT have the flicker effect! Very nice! Thanks a lot!

However, it has another effect: it ignores the scale settings of my XFCE window manager and also ignores the GDK_SCALE environment variable. So when started in GUI mode things are very tiny on my 4K display.

As a workaround I can call your official GTK2-binary from RealTimeSync in batch mode and use the Ubuntu GTK3-binary when starting GUI mode. This works for me.

But wouldn't it be nice to fix this also with GTK3? :)

[Zenju]

Yes, it would. Unfortunately GTK3 introduced fundamental changes that effectively make it impossible to correctly layout a window, without showing it first. Thous the short window flash you're seeing. No such issue with GTK2. This is probably the prime reason why the offical FreeFileSync is still compiled against GTK2. The "price" is lack of high DPI support.

viewtopic.php?t=10103
https://github.com/wxWidgets/wxWidgets/issues/16088

GTK+ 3.6 introduced caching of widget styling information. This cache is only updated at particular times of GTK's choosing. AFAICT there is no way to get the cache to be updated at any other time

There are no performance issues with GTK2. I really have no idea why this caching was "needed" in GTK3...

[bselu]

Bummer.

Thanks for the info anyway.

I guess the issue still exists with GTK4 as well?

[Zenju]

With GTK 4 it's even worse than 3. I'm not sure there will be support (ever?):
https://www.wxwidgets.org/blog/2021/01/wxwidgets-in-2020-and-beyond/

In particular, this version unfortunately won’t support GTK 4 as its API is so incompatible with the previous GTK versions that huge parts of wxGTK would have to be rewritten and we currently don’t have any resources for this

[bgstack15]

GTK3 and now 4 have always had their own bizarre choices and ignore any downstream developers and users. It's a nice toolkit, if the quirks aren't breaking features you wish to use.