LINUX.ORG.RU

Файловый диалог GTK при открытии указывает на «недавние документы»


0

0

Использую Debian wheezy (testing). С недавних пор (месяц или два), не иначе как в результате обновления, диалог открытия/сохранения файлов начал по умолчанию указывать на псевдосписок «Недавние документы». Наблюдаю такое поведение как минимум в GIMP и chromium.

Раньше, помнится, он, если программа явным образом не переопределяла каталог, открывался в домашнем каталоге. И это меня устраивало, когда как новое поведение раздражает.

Можно ли вернуть старое поведение диалога? Есть ли, например, какой-нибудь волшебный ключик для gconf или опция в .gtkrc?


для gtk2:
Никак, с версии libgtk 2.24.6 в коде gtkfilechooserdefault.c железно прописали использовать recent. Пропатчи и пересобери как тебе нужно, это тривиально.
Облегчить списки recent можно параметром
gtk-recent-file-max-age

для gtk3:
org.gtk.settings.file-chooser:last-folder-uri='по умолчанию пустой'

bass ★★★★★ ()
Ответ на: комментарий от bass

для gtk2: Никак, с версии libgtk 2.24.6 в коде gtkfilechooserdefault.c железно прописали использовать recent.

Ох, как же я не люблю такие навязанные инновации…

для gtk3: org.gtk.settings.file-chooser:last-folder-uri='по умолчанию пустой'

Спасибо, выставил. Жаль вот только и гимп, и хромиум пока с gtk2 линкуются.

rhash ()
Ответ на: комментарий от leave

Ну раньше был железно прописан user_home, а recent более подходит по логике.

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

bass ★★★★★ ()
Ответ на: комментарий от bass

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

Схерали, простите? Это как раз задача тулкита - запоминать путь открытия последнего файла, а также предоставлять возможность для пользователя глобально запретить такое запоминание и указать дефольный путь. Это очевидно любому здравомыслящему человеку, кроме разработчиков gtk.

geekless ★★ ()
Ответ на: комментарий от baverman

Страшненько добавить 2 коротких функции на сохранение-восстановление пути?

всё-таки, простой графический тулкит.

А давай без фанатизма. Есть такая штука — диалог открытия/сохранения файла. Она должна решать одну задачу и решать её хорошо. Всё, что касается вопросов её юзабилити должно быть в ней же и инкапсулировано. (Вообще по логике она отдельным бинарником должна быть, но до таких «высот» инженерной мысли разрабам gtk не подняться, уже не надеюсь.)

geekless ★★ ()
Ответ на: комментарий от geekless

Она должна решать одну задачу и решать её хорошо.

В том-то и дело, твой вариант не гибок. А если мне надо помнить последние пути для разных сайтов в браузере? Это задача приложения, только оно может предоставить их для диалога.

Вообще по логике она отдельным бинарником должна быть

И которому должен передаваться путь, не так ли?

baverman ★★★ ()
Ответ на: комментарий от baverman

В том-то и дело, твой вариант не гибок. А если мне надо помнить последние пути для разных сайтов в браузере? Это задача приложения, только оно может предоставить их для диалога.

Посмотри еще раз на путь к кэшу и обрати внимание на поле dialogid. Мой вариант гибок.

И которому должен передаваться путь, не так ли?

Ему - опции, от него - путь к файлу. Во входных опциях может быть и путь к конкретному каталогу (или идентификатор кэша, ага), но это не значит, что он _обязан_ быть.

geekless ★★ ()
Ответ на: комментарий от geekless

Тулкит предоставляет приложениям единое хранилище настроек. Приложение вольно записать или не записать туда свои параметры. Если приложение не передаёт свои параметры в диалог - диалог берёт путь по умолчанию. Это логично? По-моему логично.

Да, функциональности «забить на пути приложений -открыть отсюда» не хватало, добавили.

как раз задача тулкита - запоминать путь открытия последнего файла.

Зачем на диалог взваливать такую обязанность как «запоминание пути»? И понадобится для каждого приложения параметр типа .app.filechooser.last-path в gconf/dconf сделать обязательным, тогда:

Диалог будет для приложения (ну скажем плеер) ещё и на каждую вкладку (плейлист) запоминать путь, если у приложения есть такая функциональость:
.app.filechooser.last-path.<уникальный хэш названия плейлиста>.last-path?

А чтобы конфиги не распухали со временем, ввести у тулкита функцию «удаления пути в конфиге диалога по требованию», если кто-то удалил плейлист?

А если это временные вкладки? Например открыл 10 документов, и в каждом меняю картинки. Сохранил, закрыл, а диалог честно записал в конфиг.
Что, придётся ввести в тулкит функцию контроля над параметром last-path.tmp, иначе как диалог распознает, что какие-то пути не нужно запоминать?

Если это путь здравомыслящего человека, то извините, я уж как-то вместе с разработчиками gtk переживу нашествие таких зравомыслящих :)

bass ★★★★★ ()
Ответ на: комментарий от bass

gconf/dconf

Ну да, хранить кэш в gconf — это очень остроумно. А вы не пробави хранить кэш в каталоге, натурально, кэша? Попробуйте, вам понравится.

geekless ★★ ()
Ответ на: комментарий от geekless

ну поменяй в моём ответе gconf на файлы кэша, суть не изменится - нужно будет вводить новые функции в тулкит. причём не 2, а ещё контроль над временными и контроль над устаревшими.
Но тогда код в приложениях распухнет. В чём тогда смыл? Если приложение всё равно придётся контролировать пути, но не самому, а через посредника.

bass ★★★★★ ()
Ответ на: комментарий от geekless

Посмотри еще раз на путь к кэшу и обрати внимание на поле dialogid.

Хе-хе. Однако ты его назвал не dialog-id-with-possible-context. То есть о возможности привязывать путь к произвольным сущностям даже не задумался.

У приложений и так уже есть куда сбрасывать свои настройки. Зачем их распылять по куче других мест? Потом получается как в kde — хрен разберешь, где что лежит.

baverman ★★★ ()
Ответ на: комментарий от bass

Я даже не знаю, что тут можно посуществу ответить, кроме man find. Если тебя так напрягает десяток лишних файлов в $XDG_CACHE_HOME, оставшихся от удаленных программ, так удали их.

С чего ты вообще взял, что эти файлы будут плодиться в больших количествах? Может ты просто чего-то не понимаешь, а лезешь критиковать? Изложи свою точку зреня внятно, без завываний про «нашествие зравомыслящих».

geekless ★★ ()
Ответ на: комментарий от baverman

Хе-хе. Однако ты его назвал не dialog-id-with-possible-context. То есть о возможности привязывать путь к произвольным сущностям даже не задумался.

Ути-пути, телепат. baverman, серьёзно. Просто признай, что сразу не заметил это поле. Твой выпад в стиле детского сада.

У приложений и так уже есть куда сбрасывать свои настройки.

В dconf? Там еще 24 буквы алфавита осталось, чтобы изобрести aconf, bconf...

В $XDG_CONFIG_HOME? Ну можешь и туда, однако на полноценную опцию это никак не тянет, это таки более кэш.

Зачем их распылять по куче других мест?

«Зачем /var, зачем /etc, зачем /usr? У приложений и так уже есть куда писать свои файлы. Зачем их распылять по куче других мест?»

А давай не будем делать так, как привычно, а будем так, как правильно. В юниксе всегда на первом месте была группировка файлов по функциональному назначению, а не по принадлежности к приложению. И это правильно. А вот свалка в ~/.programname — это привычно, но нифига не правильно.

geekless ★★ ()
Ответ на: комментарий от geekless

Нежнее geekless, ещё нежнее. (с) Я тебя не троллю.

Считаю, что путями приложения должно управлять приложение, а не тулкит. Точка зрения изложена выше, ты ей оппонировал.

По твоей точке зрения я задал вопросы, причём писал их до того, как ты представил свой вариант с кэшем. Но всё равно моя точка зрения не изменилась, потому, что твоё решение не полное:
Как истинный хомячок, я не только ежедневно ставлю/удаляю с десяток программ (половина ещё сегфолтится на самом интересном месте), но у меня ещё часто отключают свет, и батарейка из ноута выпадает. А man find не хочу изучать, и вообще, как юзер не знаю о существовании XDG_CACHE_HOME и о том что, какой-то там примитивный виджет оставляет лишние файлы в системе.

bass ★★★★★ ()
Ответ на: комментарий от bass

Т.е. когда приложение само оставляет лишние файлы — это нормально, а когда библиотека в этом же приложении, то тебя это очень беспокоит.

У тебя по сути дела есть что сказать?

geekless ★★ ()
Ответ на: комментарий от baverman

У приложений и так уже есть куда сбрасывать свои настройки. Зачем их распылять по куче других мест? Потом получается как в kde — хрен разберешь, где что лежит.

вообще-то, filechooser.ini и так существует. и тулкит хранит там хренову тучу настроек. и почему-бы не добавить еще одну - путь по-умолчанию?

ananas ★★★★★ ()
Ответ на: комментарий от geekless

Если тебе важно, чтобы последнее слово было за тобой, да будет так: ты прав и всё такое.

bass ★★★★★ ()
Ответ на: комментарий от ananas

и почему-бы не добавить еще одну - путь по-умолчанию?

Ради бога. Простым приложениям этого, действительно, хватит. Но geekless чем-то упоролся сегодня и хочет перетащить туда специфичную для приложений логику, когда нужно хранить несколько последних путей. Разговор и спор об этом.

baverman ★★★ ()
Ответ на: комментарий от baverman

несколько - действительно не надо. а последнюю открытую, так-же как и отображение/скрытие адресной строки, даты и дот-файлов - кому-то возможно и было бы полезно

ananas ★★★★★ ()
Ответ на: комментарий от baverman

перетащить туда специфичную для приложений логику, когда нужно хранить несколько последних путей

Сфигали она специфична для приложений?

geekless ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.