3 ms·

Just for font rendering you need harfbuzz+freetype if you want something decent (e.g not stb_truetype) so you're already talking 5-8 mb of libraries at the bare

Just for font rendering you need harfbuzz+freetype if you want something decent (e.g not stb_truetype) so you're already talking 5-8 mb of libraries at the bare minimum. You also want ICU for proper unicode processing unless you don't have any unicode string operation anywhere in your software . +16 mb and we haven't rendered a single pixel. Then you're making a GUI - you aren't going to restrict it to people with a GeForce RTX1070+ right ? No, you want everyone to be able to use it, yes, including that one person in the back with a GMA500 intel chipset which does not support opengl 3.2 but will leave an absolutely scathing review of your app if it does not work on their machine (alternative: same thing but it's the company you're building the software for which had a fleet of 2008 dell Inspiron for their employees). So now you need to ship ANGLE + some software opengl implementation so that people with 2008 eeePCs won't see a black square when they open your app. Add 10 or so more megabytes and you have the very, very, very bare minimum on which to start building your UI toolkit if you want to cover common use cases.

cryo 4y ago
These are valid points, I'm currently going through the dance of building a custom cross platform gui for mobilde+desktop tailored to my application. Proper localized text rendering is hard, Harfbuzz and Freetype are solid options to start with and are available on recent Linux desktops. I've abstracted the text rendering to replace Harfbuzz and Freetype with platform native libraries on Apple and Windows. The renderer itself is abstracted and defaults to opengl 3.3 with a fallback to software rendering as last resort and to be portable. Long story short: It's not easy but very possible to build a polished cross-platform GUI smaller than 1MB. My app binary currently compiles down to 135 KB on desktop, in the end I aim for less than 2 MB for the whole application. However I wouldn't recommend this for most applications where a framework would be a faster option for a traditional GUI.
- jcelerier 4y ago
  > I've abstracted the text rendering to replace Harfbuzz and Freetype with platform native libraries on Apple and Windows. I hope your UI designers are happy with some text wrapping on one platform and not another because they have slightly different metrics even given the same font - for me this has never flown and I had to work to make things pixel-perfect across mac / windows / linux a few times now which definitely does not work when using the platform renderers.
- andydotxyz 4y ago
  This is dynamically linked to all those libraries which must be installed. One of the points above is how small can you be without those dependencies. All Fyne apps need is a working graphics driver capable of OpenGL spec from 2011.
hsn915 4y ago
I found the following file size for library files on my system: 816K /usr/local/opt/freetype/lib/libfreetype.a 1.9M /usr/local/opt/harfbuzz/lib/libharfbuzz.a 2.1M /usr/local/opt/sdl2/lib/libSDL2.a I don't think people really mind a 20MB executable if it was a self contained application with good performance and UI.
- andydotxyz 4y ago
  Fyne manages to be below 10MB for a stand-alone application. A future release where we add more complete language support might have to be 12.5MB entry point sadly, but it’s still small by modern app standards.
PainfullyNormal 4y ago
Everything you just described takes work, but it isn't difficult. Applications both desktop and mobile have been doing all of that for decades now. Why hasn't somebody in the Go community managed it at some point in the past 10 years?

cryo 4y ago

These are valid points, I'm currently going through the dance of building a custom cross platform gui for mobilde+desktop tailored to my application. Proper localized text rendering is hard, Harfbuzz and Freetype are solid options to start with and are available on recent Linux desktops. I've abstracted the text rendering to replace Harfbuzz and Freetype with platform native libraries on Apple and Windows. The renderer itself is abstracted and defaults to opengl 3.3 with a fallback to software rendering as last resort and to be portable. Long story short: It's not easy but very possible to build a polished cross-platform GUI smaller than 1MB. My app binary currently compiles down to 135 KB on desktop, in the end I aim for less than 2 MB for the whole application. However I wouldn't recommend this for most applications where a framework would be a faster option for a traditional GUI.

jcelerier 4y ago
> I've abstracted the text rendering to replace Harfbuzz and Freetype with platform native libraries on Apple and Windows. I hope your UI designers are happy with some text wrapping on one platform and not another because they have slightly different metrics even given the same font - for me this has never flown and I had to work to make things pixel-perfect across mac / windows / linux a few times now which definitely does not work when using the platform renderers.
andydotxyz 4y ago
This is dynamically linked to all those libraries which must be installed. One of the points above is how small can you be without those dependencies. All Fyne apps need is a working graphics driver capable of OpenGL spec from 2011.

hsn915 4y ago

I found the following file size for library files on my system: 816K /usr/local/opt/freetype/lib/libfreetype.a 1.9M /usr/local/opt/harfbuzz/lib/libharfbuzz.a 2.1M /usr/local/opt/sdl2/lib/libSDL2.a I don't think people really mind a 20MB executable if it was a self contained application with good performance and UI.

andydotxyz 4y ago
Fyne manages to be below 10MB for a stand-alone application. A future release where we add more complete language support might have to be 12.5MB entry point sadly, but it’s still small by modern app standards.

PainfullyNormal 4y ago

Everything you just described takes work, but it isn't difficult. Applications both desktop and mobile have been doing all of that for decades now. Why hasn't somebody in the Go community managed it at some point in the past 10 years?