resources.qrc contains WAY too much stuff #458

New Issue

2018-06-06T12:53:45+02:00

buzztiaan commented

2018-06-06 12:53:45 +02:00

(Migrated from github.com)

Could we move files to files, and maybe just -not- stuff them in the binary?
-or- split resources.qrc to seperate files.

As-is this method of 'lets make a 0.5M line C++ file' causes a lot of compilation issues for anyone with a small system (raspi and friends) , at the price of near zero gains?

Why not keep .ttf files as .ttf files, so people can just see them, whats there to gain here.

Could we move files to files, and maybe just -not- stuff them in the binary? -or- split resources.qrc to seperate files. As-is this method of 'lets make a 0.5M line C++ file' causes a lot of compilation issues for anyone with a small system (raspi and friends) , at the price of near zero gains? Why not keep .ttf files as .ttf files, so people can just see them, whats there to gain here.

👍 1

buzztiaan commented

2018-06-06 13:45:57 +02:00

(Migrated from github.com)

it takes -2GB- ram just to wrap some .png and .ttf files into a .cpp ? geez , how pointless

pazos commented

2018-07-13 03:03:21 +02:00

(Migrated from github.com)

resources bundled with the application is a nice way of abstract OS depedant path for loading resources (inside bundles on mac, on the same path of the app on windows, following FHS on linux/bsd). It is actually faster to load resources that way instead of loading them from the filesystem.

Also the other option is to integrate a build system for mac (which bundles everything on a app bundle or dmg disk), and refine the make install method for linux. But this is a lot of work just to remove a few KB of an application.

About RPi, did you try to cross compile, this is great. Other option is a big swap file 👍

resources bundled with the application is a nice way of abstract OS depedant path for loading resources (inside bundles on mac, on the same path of the app on windows, following FHS on linux/bsd). It is actually faster to load resources that way instead of loading them from the filesystem. Also the other option is to integrate a build system for mac (which bundles everything on a app bundle or dmg disk), and refine the `make install` method for linux. But this is a lot of work just to remove a few KB of an application. About RPi, did you try to cross compile, this is great. Other option is a big swap file 👍

yurikhan commented

2018-07-13 11:35:22 +02:00

(Migrated from github.com)

The argument against resource bundles is not just about loading performance or build performance or binary size. The point is, bundling makes it hard to use the bundled resources in applications other than the one they are bundled with; and it makes it hard to customize the application.

Reasonable use case 1: If I can use a retro font in a retro terminal emulator, I should be able to easily use that same font in a modern text editor running beside that terminal emulator.

Reasonable use case 2: If I have a font on my system that is not provided along with the application (possibly because it is non-free, or free for personal use but not redistribution), I should be able to use it with the terminal emulator without having to rebuild it from source.

The argument against resource bundles is not just about loading performance or build performance or binary size. The point is, bundling makes it hard to use the bundled resources in applications other than the one they are bundled with; and it makes it hard to customize the application. Reasonable use case 1: If I can use a retro font in a retro terminal emulator, I should be able to easily use that same font in a modern text editor running beside that terminal emulator. Reasonable use case 2: If I have a font on my system that is not provided along with the application (possibly because it is non-free, or free for personal use but not redistribution), I should be able to use it with the terminal emulator without having to rebuild it from source.

buzztiaan commented

2018-07-13 13:05:45 +02:00

(Migrated from github.com)

POSIX should make sure you have OS independent paths , that's why they wrote it in the 60s

either way, -only- this resources method makes cool retro term a 'heavy' application on many systems, avoiding it would make it more like a terminal emulator

POSIX should make sure you have OS independent paths , that's why they wrote it in the 60s either way, -only- this resources method makes cool retro term a 'heavy' application on many systems, avoiding it would make it more like a terminal emulator

👍 1

alexmyczko commented

2020-01-14 08:36:33 +01:00

(Migrated from github.com)

system fonts are supported! (on linux here, qt5 on debian sid)

if you want to give it a try: http://sid.ethz.ch/debian/cool-retro-term/2020/

system fonts are supported! (on linux here, qt5 on debian sid) if you want to give it a try: http://sid.ethz.ch/debian/cool-retro-term/2020/

Sign in to join this conversation.