ультралегкое приложение на Qt

[Fess]

Всем доброго времени суток!
Мне нужно максимально облегченное по потреблению ресурсов приложение.
Это просто иконка в трее, которая по желанию юзера запускает те или иные действия основного "тяжелого" приложения.
Сборка всего с core & gui занимает 8-10 Мб памяти в релизе.
Кто может меньше?

[GreatSnake]

Кто может меньше?

WinAPI либо Xlib)

[Fess]

хотелось бы остаться на Qt..
нужно кросс-платформенное решение

[GreatSnake]

Сборка всего с core & gui занимает 8-10 Мб памяти в релизе.

Т.е. запущенное приложение в памяти столько занимает или?

[LisandreL]

хотелось бы остаться на Qt.
нужно кросс-платформенное решение

Тогда смиритесь с размером.
Если важен размер дистрибутива, то некоторый выигрыш даст статическая пересборка без лишнего, вроде q3-support и т.п.
Большой выигрышь в объёме даст вам upx (получал бинарники меньше 4 метров).
Но всё равно ультратонким, без отказа от Qt классов, ваше приложение не будет.

[Denjs]

+1.
Qt дает кроссплатформенность, удобство и независимость, но за все надо платить.
Вам надо таскать с собой библиотеки. Минимум что вам понадобится - это релизные билиотеки QtGui и ещё что-то.... в 16 мб переносимого дистритутива вы уложитесь.

Это точно так-же как любое дот-нет приложение требует тянуть и обнослять для себя нет-фреймворк с оффсайта майкрософта. иначе оно рпосто работать не будет (и это при том, что дот-нет не дает и рядом особо того же что Qt).

Хотите "ультра-легкое" - используйте только то , что идет в поставке и операционной системой.

Но имхо - 16-30 мб библиотек - таскаемых вместе с приложением, да 30-40 мб в памяти для полновесного гуи-прилодения - имхо сегодня это - ну "такие мелочи".... имхо))))

я клиентам по 200 мб приложения в дебаг-сборках отдавал - и все довольны были  

[Fess]

борьба за место в оперативке и только..
upx может дать какой-либо выигрыш по памяти?
может какие-нибудь флаги компилера/линкера посоветуете?

[asvil]

О придумал. Cпилите исходники qtsystemtrayicon, правда кроме них еще какой-никакой eventloop понадобиться.

А вообще, вообще. Нафик вашему "Пользователю" этот fast access to application. Я вот например никогда не пользуюсь. Вы может пожалейте его панельку с часиками.
Там еще у виндусовых пользователей куча граф., звук. драйверов, антивирусов, статус сети...можно до бесконечности.

[GreatSnake]

Cпилите исходники qtsystemtrayicon

Кстати, верная идея.
Нужно только переписать QSystemTrayIcon так, чтобы он не использовал  QIconEngine/QImageReader/QFontEngine/QFontDatabase и др. тяжелые вещи.
Только вот нужно ли это?

[LisandreL]

upx может дать какой-либо выигрыш по памяти?

Какой-то может, но скорее всего идёт распаковка оригинального исполняемого файла в память и выйдет тож на тож.
Вообще попробую завтра провести эксперимент.

[LisandreL]

Вообще попробую завтра провести эксперимент.

Итак, тестовая программа:

Код

C++ (Qt)
#include <QApplication>
#include <QSystemTrayIcon>
#include <QMenu>
#include <QProcess>
#include <QTextCodec>
 
class MyMenu: public QMenu
{
Q_OBJECT
public:
    MyMenu()
    {
        addAction( "Командная строка", this, SLOT( startCMD() ) );
        addAction( "Блокнот", this, SLOT( startNotepad() ) );
        addAction( "Калькулятор", this, SLOT( startCalc() ) );
        addSeparator();
        addAction( "Закрыть", qApp, SLOT( quit() ) );
    }
private slots:
    void startCMD()
    {
        QProcess::startDetached( "cmd" );
    }
    void startNotepad()
    {
        QProcess::startDetached( "notepad" );
    }
    void startCalc()
    {
        QProcess::startDetached( "calc" );
    }
};
 
int main(int argc, char *argv[])
{
    QTextCodec::setCodecForCStrings( QTextCodec :: codecForName( "CP1251" ) );
    QApplication a(argc, argv);
    QSystemTrayIcon systemTrayIcon;
    MyMenu menu;
    QPixmap pixmap(16,16);
    pixmap.fill( Qt::darkRed );
    systemTrayIcon.setIcon( QIcon( pixmap ) );
    systemTrayIcon.setContextMenu( &menu );
    systemTrayIcon.show();
    int result = a.exec();
    systemTrayIcon.hide();
    return result;
}
 
#include "main.moc"

Прараметры:
ос - Windows 7 x64
компилятор - mingw
Qt - 4.7.3

1) Динамическая сборка
Место на диске: 12 525 666 байт (c dll)
Память (рабочий набор/частный рабочий набор/выделенная память): 6 864КБ, 1 176КБ, 2 948КБ.

2) Статическая сборка ( -static -release -no-exceptions -no-qt3support -nomake demos -nomake examples )
Место на диске: 8 766 976 байт
Память (рабочий набор/частный рабочий набор/выделенная память): 5 864КБ, 1 048КБ, 2 668КБ.

3) Статическая сборка + upx ( --ultra-brute )
Место на диске: 2 831 872 байт
Память (рабочий набор/частный рабочий набор/выделенная память): 13 256КБ, 9 788КБ, 9 988КБ.

Очевидно upx распаковывает сжатый оригинальный исполняемый файл в память, поэтому для экономии памяти он непригоден.

[lit-uriy]

>>но скорее всего идёт распаковка оригинального исполняемого файла в память
распаковка идёт во временный каталог, а оттуда запуск. Отсюда проблема - текущий путь к приложению не тот, где лежал сжатый бинарь.

П.С.
В доке про UPX это явно сказано

[lit-uriy]

по поводу облегчения:
можно самому собрать Qt с определённым конфигом, тыц

[LisandreL]

Отсюда проблема - текущий путь к приложению не тот, где лежал сжатый бинарь.

Под Windows нет такой проблемы - qApp->applicationDirPath() и qApp->applicationFilePath() возвращают правильные пути, да и судя по объёму занятой памяти извлечение идёт именно туда.

[lit-uriy]

>>Под Windows нет такой проблемы - qApp->applicationDirPath()
У меня под виндовоз именно этот метод возвращал путь к %TEMP%.
также себя вели и пути заданные через "этот" каталог (".")

П.С,
пробовал UPX 1,5 года назад. Может что-то и изменилось с тех пор