Модератор: /dev/random
Я не ставил и не ставлю себе такой цели. Хотя теперь есть повод для сравнения.
Что касается "копировать на флешку" - не беспокойтесь. Картинки этому _уже_ не мешают. Ориентировочный конечный объем программы будет вряд ли больше 400КБайт. Сейчас - порядка 300 КБайт. На флешку влезет без проблем.
YUKLA писал(а): ↑11.10.2009 10:15Ну, не знаю - стоит ли мне копировать творчество программистов KDE...
ИМХО - решение это не менее спорное. И органически смотрится и хорошо подходит для _встроенной_ утилиты. Но не для отдельной программы. ИМХО.
Что касается "копировать на флешку" - не беспокойтесь. Картинки этому _уже_ не мешают. Ориентировочный конечный объем программы будет вряд ли больше 400КБайт. Сейчас - порядка 300 КБайт. На флешку влезет без проблем.
Вы можете обосновать сие смелое утверждение?
YUKLA писал(а): ↑11.10.2009 15:48Вы можете обосновать сие смелое утверждение?
Приведите, пожалуйста, пример аналогичной программы. Аналогичной по функционалу и по сложности кода. Лучше - своей.
Просто для справки - сейчас в проекте порядка 18 тыс. строк кода.
И, опять же - ну при чем тут "C++/Qt"? На текущий момент программа не содержит "лишнего" кода и по своей бинарной структуре НИЧЕМ не отличается от любой другой Линукс-программы, написанной на том же C/C++. Например, ничем принципиально не отличается от того же Abiword. Или GIMP.
К тому же, общий объем кода, ответственного за интерфейс - немногим более 2 тыс. строк.
На счет Qt. Выбор Qt как основной библиотеки для универсальной программы - в корне не правильное решение. Оно ограничивает использование программы миром пользователей KDE. А GTK есть у всех. Вот, когда GIMP переведут на Qt - вот тогда будет смысл подумать. А пока - извините - Qt - не самый лучший выбор.
, среди которых есть и немного моих. Код: Выделить всё
negativ@negativ:~/eiskaltdc-trunk$ find eiskaltdc -type f -name *.cpp -exec cat {} \; | wc -l
36798YUKLA писал(а): ↑11.10.2009 15:48На счет Qt. Выбор Qt как основной библиотеки для универсальной программы - в корне не правильное решение. Оно ограничивает использование программы миром пользователей KDE. А GTK есть у всех. Вот, когда GIMP переведут на Qt - вот тогда будет смысл подумать. А пока - извините - Qt - не самый лучший выбор.
YUKLA писал(а): ↑10.10.2009 22:53Ну - это вопрос не ко мне. А к соотв. коммьюнити соотв. Linux-дистрибутивов. Пусть соберутся вместе и договорятся о стандартных пакетах шрифтофф. Или хотя бы о стандартах fonts substitution.diesel писал(а): ↑10.10.2009 22:48YUKLA писал(а): ↑10.10.2009 22:43Еще раз - посмотрите в настройки Audacious - и вы увидите возможность менять шрифты как всего интерфейса, так и его отдельных частей. Pidgin пришел к этому принципу управления настройками только к версии 2.6.0.
правильный путь, если с точки зрения пользователя, - это не заставлять пользователя париться по поводу смены шрифтов вообще. чем меньше исключений из этого правила - тем удобнее пользователю.
diesel писал(а): ↑11.10.2009 16:33какой из этих выборов ваше приложение использует? Если смотреть на скриншот RasenHerz, то там:
- верхние табы, и нижняя строчка с кнопками, используют один шрифт
- То что помечено стрелочками "ужасно" - используют другой шрифт(причем жирный и поменьше)
- Колонка справа прорисована третьим шрифтом - он моноширинный? - в моноширинном шрифте там был бы смысл если бы хотелось колонку результатов сделать таки колонкой
drBatty писал(а): ↑11.10.2009 16:41diesel писал(а): ↑11.10.2009 16:33какой из этих выборов ваше приложение использует? Если смотреть на скриншот RasenHerz, то там:
- верхние табы, и нижняя строчка с кнопками, используют один шрифт
- То что помечено стрелочками "ужасно" - используют другой шрифт(причем жирный и поменьше)
- Колонка справа прорисована третьим шрифтом - он моноширинный? - в моноширинном шрифте там был бы смысл если бы хотелось колонку результатов сделать таки колонкой
это да... к программе нужен конфиг... Я надеюсь, что он скоро будет.
diesel писал(а): ↑11.10.2009 16:33какой из этих выборов ваше приложение использует? Если смотреть на скриншот RasenHerz, то там:
- верхние табы, и нижняя строчка с кнопками, используют один шрифт
- То что помечено стрелочками "ужасно" - используют другой шрифт(причем жирный и поменьше)
- Колонка справа прорисована третьим шрифтом - он моноширинный? - в моноширинном шрифте там был бы смысл если бы хотелось колонку результатов сделать таки колонкой
Рылли? А по мне - так вполне форматируется. Отступ 30 - strlen(cName).
Код: Выделить всё
[vasiliy@eifel ~]$ uname -a
Linux eifel 2.6.30-ARCH #1 SMP PREEMPT Wed Sep 9 14:16:44 CEST 2009 x86_64 Intel(R) Core(TM)2 Duo CPU T5550 @ 1.83GHz GenuineIntel GNU/LinuxYUKLA писал(а): ↑12.10.2009 00:19
Вы хотите, чтобы было так?
Это скриншот примера из gtk-demo. Как вы видите - шапка TreeView _фиксирует_ размер колонок TreeView. И колонки в subtree _не смещаются_ и размещаются так, как и колонки-родители.
Мне лично ТАК не нравится. Более того. Размер cName (наименования параметра) _заранее_ не известен. И может быть как меньше 30 символов. так и много больше - к примеру, у меня в дереве X11 есть позиции, где отступ составляет не 30 единиц, а 54.
Что вы предложите?
YUKLA писал(а): ↑12.10.2009 00:26Мне на данном этапе нужны нормальные, адекватные тестеры. Которые смогут протестировать мою программу и дать мне возможность исправить ошибки. Опыт показывает, что я лично трачу на исправления одной отдельно взятой ошибки примерно 1 (Один) день работы при наличии адекватного тестера и хорошо налаженного обмена с ним.
YUKLA писал(а): ↑12.10.2009 00:26Мне на данном этапе нужны нормальные, адекватные тестеры. Которые смогут протестировать мою программу и дать мне возможность исправить ошибки. Опыт показывает, что я лично трачу на исправления одной отдельно взятой ошибки примерно 1 (Один) день работы при наличии адекватного тестера и хорошо налаженного обмена с ним.
RasenHerz писал(а): ↑12.10.2009 02:04Открыв исходники вы можете получить:
1) Патчи (причем иногда крайне полезные, к примеру, мне присылали патчи которые в разы ускоряют сортировку, делают код более читабельным и ясным)
2) Экономию времени при тестировании программы (несколько человек всегда отыщут больше ошибок и "узких" мест в коде)
3) Более быстрое и эффективное развитие кодовой базы (если таковое вообще возможно)
Как видите никакой религии и фанатизма - я аргументировал свое предложение.
YUKLA писал(а): ↑12.10.2009 09:08RasenHerz писал(а): ↑12.10.2009 02:04Открыв исходники вы можете получить:
1) Патчи (причем иногда крайне полезные, к примеру, мне присылали патчи которые в разы ускоряют сортировку, делают код более читабельным и ясным)
2) Экономию времени при тестировании программы (несколько человек всегда отыщут больше ошибок и "узких" мест в коде)
3) Более быстрое и эффективное развитие кодовой базы (если таковое вообще возможно)
Как видите никакой религии и фанатизма - я аргументировал свое предложение.
За время существования ветки я ни разу не получал предложений о помощи в кодировании. Более того, ни разу я не получал и советов КАК сделать то или иное действие с системными запросами, в случае, если я испытывал в этом затруднение. На мои прямые вопросы с приведёнными примерами кода ответом было недоуменное молчание.
Отсюда я заключаю, что как минимум в данной ветке специалистов, которые могли бы реально помочь мне решить сложные для меня вопросы ПРОСТО НЕТ.
Основные советы, которые мне тут дают, можно отнести к двум классам - это "открытие исходников" и "изменения внешнего вида". Ни в том, ни в другом я не нуждаюсь.
Bluetooth писал(а): ↑12.10.2009 09:20Нормальные люди не станут пытаться помочь закрытому проекту.
Не говоря уж о том, что люди, которые помогают проекту, появляются отнюдь не на форуме.
И, наконец, не вижу препятствий к тому, чтобы открыть исходники. Хуже уж точно не будет. А потенциальные преимущества раскрыты выше.
YUKLA писал(а): ↑12.10.2009 09:24Bluetooth писал(а): ↑12.10.2009 09:20Нормальные люди не станут пытаться помочь закрытому проекту.
Не говоря уж о том, что люди, которые помогают проекту, появляются отнюдь не на форуме.
И, наконец, не вижу препятствий к тому, чтобы открыть исходники. Хуже уж точно не будет. А потенциальные преимущества раскрыты выше.
Нормальные люди будут помогать любому проекту. А фанатики - будут повторять бесконечные бессмысленные мантры про "открытые исходники". Пользуясь при этом проприентарными драйверами ATI, NVidia, "писалкой" Nero, сканером VueScan (еще и ломанными в добавок) и так далее.
YUKLA писал(а): ↑12.10.2009 09:08А нуждаюсь я вот в чем. Например, на данный момент я борюсь с функцией _XSend(). Которая работала в X.Org Server 1.5.3 и перестала работать в X.Org Server 1.6.xx, вызывая ошибку "Fatal IO error 11 (Ресурс временно недоступен) on X server :0.0." Исследования показали, что проблема, скорее всего, кроется в неверно указанной длине запроса (req->length). Но могут быть и другие варианты...
Кто-нибудь может мне помочь в этом?
Коллега, перечитайте тему с самого начала - многие вопросы к автору отпадут.RasenHerz писал(а): ↑12.10.2009 02:04
Открыв исходники вы можете получить:
1) Патчи (причем иногда крайне полезные, к примеру, мне присылали патчи которые в разы ускоряют сортировку, делают код более читабельным и ясным)
2) Экономию времени при тестировании программы (несколько человек всегда отыщут больше ошибок и "узких" мест в коде)
3) Более быстрое и эффективное развитие кодовой базы (если таковое вообще возможно)
Как видите никакой религии и фанатизма - я аргументировал свое предложение.
YUKLA писал(а): ↑12.10.2009 09:08А нуждаюсь я вот в чем. Например, на данный момент я борюсь с функцией _XSend(). Которая работала в X.Org Server 1.5.3 и перестала работать в X.Org Server 1.6.xx, вызывая ошибку "Fatal IO error 11 (Ресурс временно недоступен) on X server :0.0." Исследования показали, что проблема, скорее всего, кроется в неверно указанной длине запроса (req->length). Но могут быть и другие варианты...
Кто-нибудь может мне помочь в этом?
Это скриншот примера из gtk-demo. Как вы видите - шапка TreeView _фиксирует_ размер колонок TreeView. И колонки в subtree _не смещаются_ и размещаются так, как и колонки-родители.
Мне лично ТАК не нравится. Более того. Размер cName (наименования параметра) _заранее_ не известен. И может быть как меньше 30 символов. так и много больше - к примеру, у меня в дереве X11 есть позиции, где отступ составляет не 30 единиц, а 54.
Что вы предложите? crazy.gif
Коллега, перечитайте тему с самого начала - многие вопросы к автору отпадут.
Здесь уже отметилась и поучаствовала большАя часть модератороского состава и немало опытных форумчан.
1. Пока что программа распространяется в формате as-is. Т.е. - в виде бинарника безо всего.... smile.gif Наверно по-тому, что она - глубокая и сырая бета.
2. Думаю - следующий шаг логичнее всего было бы сделать в сторону организации SourceForge странички и открытии кода
3. Ну а остальное - уж потом. Плюс - пишу я на FPC/Lazarus. Такую программу достаточно сложно распространять в виде исходников. Чисто технически. tongue.gif Ведь для ее сборки нужен не только FPC, но еще и Lazarus (хотя бы библиотеки LCL).