Re: Palitra
Posted: Thu Nov 07, 2013 8:38 pm
Тогда можно изменить саму структуру: Autorun.dat -> Autorun.ini, дабы стало проще редактировать.
краткость сестра таланта!Heavyiron wrote:eAndrewНасколько я понял Akultist, имелось в виду, что с тем же успехом можно менять строчку в autorun.dat вместо того, чтобы держать ее в wallpaper.dat.
для ini оно конечно проще, но это файл запуска для лаунчера, ему как бы удобнее без ini. Я бы не обиделся если бы фон устанавливал лаунчер, как параметры к запуску - но опять таки это не его прирогатива - это должна делать спец программа.eAndrew wrote:Тогда можно изменить саму структуру: Autorun.dat -> Autorun.ini, дабы стало проще редактировать.
У DAT файлов структуры не стандартизированы - это введет дополнительную путаницу, если INI файл не будет таковым на самом деле.eAndrew wrote:Тогда можно изменить саму структуру: Autorun.dat -> Autorun.ini, дабы стало проще редактировать.
Code: Select all
VMware® Workstation (Version 7.0.1 build-227600)
Host OS version: Windows 7 Professional, 64-bit 6.1.7601, Service Pack 1
CPU: Intel Core i5-3570 @ 3.40 GHz
RAM: 8GB
Уточнение: PIC4 не "выпилена" (и даже не "выпилина"), а Leency удалил её из автосборки в SVN r3087 07/12/2012 (в той же ревизии, в которой он добавил Palitra). Поскольку Palitra не предоставляет полностью всю функциональность, которую имела PIC4, хотелось бы узнать о причинах её удаления, а также планируется ли добавить эту функциональность в Palitra, или я могу вернуть в автосборку PIC4 (не убирая Palitra)?Leency wrote:Залил на SVN версию 0.4 + кнопка background, добавил программу в автосборку.
Т.к. PIC4 выпилина, нужно добавить в программу автозапуск с параметром установки цвета рабочего стола. Что-то вроде:
palitra bg#FFFCCC.
В данном случае, нужно, чтобы заменить фоновую картинку в автосборке на сплошной цвет (не чёрный).
Есть новости? Будешь на текстовый файл переделывать?eAndrew wrote:Программа не изменяла цвет в Autorun.dat и юзер об этом файле тоже может не знать. Теперь при нажатии на BACKGROUND фон в файле тоже переписывается./RD/1/MEDIA/PALITRA "H 007DCEDF 003C427F" 1 #SET BG
1) Насколько я знаю сорцов этой программы на SVN нет, хоть автор и обещал(Так, во всяком случае, работает Pipetka от Rock_maniak_forever.)
Уже упомянутая выше Pipetka (только в русской автосборке).
1) данную функциональность предполагается выпилить из Palitra (с корнем). Такими вещами должна заниматься отдельная специализированная программа (управление скином, фоном, и т.д.). Эта функциональность временная!не предоставляет полностью всю функциональность, которую имела PIC4, хотелось бы узнать о причинах её удаления, а также планируется ли добавить эту функциональность в Palitra
CSLIDE и COLORREF - это демки, по моему мнению их удалять не стоит. это наглядное пособие, посмотрев их можно понять где можно подсмотреть реализацию. ИМХО - они в любом случае должны остаться! (ну разве что под что-то важное не будет хватать места). (это не вырвано из контекста, я отписался только по демкам в этом посте - речь шла о замене 4 программ )2) COLORREF в папке DEMOS - умеет писать название цвета, и отображает HEX-код и название для двух цветов сразу
3) CSLIDE в папке DEMOS - "возможность таскать ползунок в регуляторе и соответственно изменение цвета на лету"
Если добавить весь этот функционал в Palitra, можно будет одной программой заменить эти 4 программы (и удалить их из автосборки).
Тут требуются некоторые уточнения:+ У всех этих 4 программ (Pipetka, PIC4, COLORREF, CSLIDE) окошечко для цвета и палитра большего размера, чем у программы Palitra, и в них легче попасть мышкой / легче рассмотреть издалека.
ПРОТЕСТУЮ! Это надо выносить в отдельную программу (а не тащить в палитру)! Палитра научилась работать с расшаренной областью памяти, поэтому ее можно будет вызывать из любой другой программы, выбирать цвет и закрывать, и она вернет выбранный цвет). НУ НЕ ДОЛЖНА ОНА ставить фон и прочую хрень! Она должна работать с выбором и подбором цвета ( и должна делать это хорошо!)Есть новости? Будешь на текстовый файл переделывать?
Я с этим согласен, это временное решение, но альтернативы пока нету. В будущем это будет в DeskCFG, но что то я заленился.ПРОТЕСТУЮ! Это надо выносить в отдельную программу (а не тащить в палитру)! Палитра научилась работать с расшаренной областью памяти, поэтому ее можно будет вызывать из любой другой программы, выбирать цвет и закрывать, и она вернет выбранный цвет). НУ НЕ ДОЛЖНА ОНА ставить фон и прочую хрень! Она должна работать с выбором и подбором цвета ( и должна делать это хорошо!)
)) Ну так не сейчас же выпиливать! Лень - двигатель прогресса!eAndrew wrote:Я с этим согласен, это временное решение, но альтернативы пока нету. В будущем это будет в DeskCFG, но что то я заленился.
Code: Select all
/media/palitra B 000E639C
Для старого как было, так и осталось H и два цвета. Ничего не урезано. По памяти храниться вся картинка width*height*3 (как, вроде бы, и для старого варианта).Mario_r4 wrote:А по памяти, потраченной на хранение картинки, на сколько отличаются старый и новый варианты?
Еще я считаю, что нужно старый вариант тоже оставить. Никто ведь не запрещает передавать первым байтом строки параметра тип заливки. A - для строго варианта и B - для нового.
Я конечно может и жмот, но все же 1024*768*3, для типичного случая запускаемого в Qemu, получается 2,25 Мб. Если в первом случае наличие градиента еще хоть как то может объяснить такую растрату памяти, то в новом варианте я не понимаю - можно же сгенерировать повторяющийся кусок и уложить его плиткой.e-andrew wrote:По памяти храниться вся картинка width*height*3 (как, вроде бы, и для старого варианта).
Да, можно. Так не сделалось из-за первоначальной задумки, которая провалилась. Сейчас такое вполне реализуемое. Учту.Mario_r4 wrote:Я конечно может и жмот, но все же 1024*768*3, для типичного случая запускаемого в Qemu, получается 2,25 Мб. Если в первом случае наличие градиента еще хоть как то может объяснить такую растрату памяти, то в новом варианте я не понимаю - можно же сгенерировать повторяющийся кусок и уложить его плиткой.e-andrew wrote:По памяти храниться вся картинка width*height*3 (как, вроде бы, и для старого варианта).
Только хотел про это написать Но всё же результат будет уже другой.Mario_r4 wrote:Я конечно может и жмот, но все же 1024*768*3
Почему? Разве в ядре не билинейная интерполяция? К примеру, в fillScr мне для градиента 2x2 понадобится 2*2*3=12. Всего каких-то 12 байт! А рисует уже само ядро.Mario_r4 wrote:наличие градиента еще хоть как то может объяснить такую растрату памяти
Скажем так - для слабых машин, а Qemu эмулирует именно слабую машину, намного предпочтительней именно плиточный режим. Он тупо быстрей... заметно быстрей.0CodErr wrote:Почему? Разве в ядре не билинейная интерполяция? К примеру, в fillScr мне для градиента 2x2 понадобится 2*2*3=12. Всего каких-то 12 байт! А рисует уже само ядро.Mario_r4 wrote:наличие градиента еще хоть как то может объяснить такую растрату памяти