Даёшь zSea в официальный дистрибутив!

Find out what others think about your ideas
  • Rock_maniak_forever, ё-моё...
    Это совершенно неважно в какой папке лижит DLL либа, потому что, как я уже говорил, расход памяти будет очень высокий, как дисковой так и оперативной памяти. Не надо кошмарить систему.
    С какой это стати? А? Расход дисковой памяти будет не больше, чем если бы подобная функциональность была "вшита" в программу без использования библиотек (библиотеками-то никто пользоваться не заставляет, хочешь - пиши свой код). В оперативную память библиотека будет загружена при работе с zSea (до тех пор, пока он не запущен, никуда твоя свободная оперативная память не денется).

    Было бы лучше по-твоему, если бы
    модули работы с изображениями различных форматов и функции поворота и масштабирования не были бы вынесены в obj-и, а были "намертво" вкомпилены в программу
    Нет, ну ты скажи? Если бы не было отдельных файлов-библиотек, а весь код был бы вшит в исполняемый файл zSea, вопросов бы не возникло?

    То, что библиотеки различного назначения есть - огромный плюс, но никто же не заставляет ими пользоваться в обязательном порядке.

    Вот, хочу я, допустим, конфигурационный файл прочитать. А libini меня по каким-то причинам не устраивает (не будем говорить, по каким именно, это просто условный пример). И? И что? Если я напишу свой код для парсинга конфигурационного файла, это будет трагедией? И программу на этом основании в дистрибутив не включат, сколь бы хороша она ни была?

    : Вот под винду Майкрософт разработал библиотеку классов MFC. И? И что? С момента выхода MFC разрабатывать программы на базе чистого WinApi стало запрещено?
    Потом .NET Framework появился. Если следовать твоей логике, то с этого момента писать программы на базе MFC и на базе чистого WinApi стало нельзя. Ты что: не дай бог напишешь что-то, что в библиотеке классов .NET уже создано до нас... Вдруг конфигурационный файл сам парсить будешь... Или BMP'шки в JPEG'и конвертировать... Или... Мало ли чего... И вообще, код для .NET Framework - управляемый и безопасный, работает под управлением виртуальной машины - не то, что "настоящий" машинный код, использующий вызовы WinApi "вручную".
    А то, что существующая реализация меня по каким-то причинам не устраивает, никого не волнует. По твоей логике, есть библиотека - ОБЯЗАН пользоваться.


    Повторяю ещё раз ключевой вопрос:
    Если бы модули работы с изображениями различных форматов и функции поворота и масштабирования не были бы вынесены в obj-и, а были "намертво" вкомпилены в программу, проблем с включением программы в дистрибутив не возникло бы???
  • Я сейчас еще немного нямки подкину.
    1) Я собираюсь переписывать KFM -Kolibri File Manager, это думаю знают многие - на форуме читали.
    2) В новом KFM будет функция предпросмотра файлов в виде эскизов документов.
    3) Угадайте с трех раз - библиотеки какой программы я буду использовать.
  • KIV???
    :lol:
    извините, не удержался :D
  • Ага, особенно его библиотеки для масштабирования и преобразования глубины цвета.
  • Андрей Михайлович, "С какой это стати? А? Расход дисковой памяти будет не больше, чем если бы подобная функциональность была "вшита" в программу без использования библиотек (библиотеками-то никто пользоваться не заставляет, хочешь - пиши свой код)." - будет таки больше, ибо отдельный файл, ибо минимальное дисковое пространство, занимаемое одним файлом довольно велико относительно размеров нашей операционной системы, и редкий файл в ней выровнен под это пространство. А если плагинов еще и несколько вместо одной библиотеки, ситуация усугубляется.

    Mario, а как будет реализован шаринг? То есть положение этих библиотек. Или новая версия KFM не будет работать в отсутствие ZSea? или плагины будут продублированы в директорию KFM, т.к. дублирование библиотек - это хорошо? Мне правда интересно.
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • Gluk
    будет таки больше, ибо отдельный файл, ибо минимальное дисковое пространство, занимаемое одним файлом довольно велико относительно размеров нашей операционной системы, и редкий файл в ней выровнен под это пространство. А если плагинов еще и несколько вместо одной библиотеки, ситуация усугубляется.
    Вообще то он имел ввиду если один и тот же код 10 и более приложений содержат в своем бинарнике, то вынесение его и в библиотеку, даже если это и дублирующая библиотека - таки даст экономию объема. Другой вопрос, что пока у нас меньше десятка приложений, которые используют вывод RAW графики. Пока.
    Mario, а как будет реализован шаринг? То есть положение этих библиотек. Или новая версия KFM не будет работать в отсутствие ZSea? или плагины будут продублированы в директорию KFM, т.к. дублирование библиотек - это хорошо? Мне правда интересно.
    Доступные мне методы.
    1) Также как и со всеми библиотеками - положив в /sys/lib/
    Cnv_png.obj там нормально уже давно лежит - никому не мешает.
    2) Прописав в INI положение папки для библиотек.
    3) Да, можно и дублировать, хотя это уже самый глупый и вредный вариант, но чего не сделаешь ради умных и талантливых людей составляющих сообщество Колибри. :lol:

    З.Ы. Вариант 1 и 2 по сути вообще не отличаются, только в варианте 2 еще и дополнительный код на получение из INI нужен.
  • Who is online

    Users browsing this forum: No registered users and 4 guests