Re: [Comm] [Antique] Развитие tray_eject

Re: [Comm] [Antique] Развитие tray_eject

[Владимир Гусев]

> Собственно письмо адресовано Юре, но посылаю в рассылку для того, чтобы  
> все участники данной рассылки были в курсе ситуации.

Правильно сделали.. Это не тот случай, когда полезнее "кулуарщина".

> Юра, так как Вы не входите в тим, то Вы не получаете писем о том, что  
> сейчас творится в сизифе. А в сизифе сейчас планируется убирать HAL.
> Я не хочу тут обсуждать почему и зачем, но предупреждаю о том, что и  
> qtrayvolman и tray_eject и tray_eject_plus используют HAL для  
> монтирования устройств.
> Что касается первого, то gns@ хочет написать свою монтировался на  
> udisks. Логику во многом возьмет из qtrayvolman. Второй я просто не буду  
> собирать, то есть удалю за ненадобностью у нас. А вот что касается  
> tray_eject_plus... Юр, решать Вам. Можно продолжать разрабатывать его  
> для 5.1, а можно связаться с gns@ и попробовать вместе  
> исправить/заменить tray_eject_plus на что-то используещее udisks.

Совсем не обязательно на данный момент все бросать и "равняться на  
знамена".. есть 5.1, вполне себе нормальный.. только дособрать для un-def  
ядра модуль ndiswrapper и больше ничего не нужно - все есть.. Что будет  
дальше - видно будет. Я бы советовал Юре не распыляться (есть еще задания,  
которые, думаю, будут ему интересны), а пока просто принять к сведению,  
что называется.. hal не умер в один миг, поэтому лучше отшлифовать то, что  
имеется на данный момент.. Нового бранча пока нет, а для старого udisks  
никто бэкпортировать наверняка не будет..

Так что мой тебе совет, Юра, для начала просто изучить матчасть - что это  
такое - udisks, и чем оно лучше hal.. А так решай сам.

Вот как в нашей "Беловежской пуще" решаются дела... сначала OSS выкинули  
одним жестом (кто будет переписывать программы, использующие /dev/mixer -  
неясно, явно не тот, кто стал инициатором выкидывания OSS), теперь hal..

Да, слухи о кончине hal как-то невзначай пробегали в рассылке.. Чем это  
грозит для обычных прикладных программ, вполне ясно из вашего письма.. Мне  
непонятно лишь одно - да, в этом случае нам повезло, есть Юра, с котором  
можно легко обсудить проблему. Но ведь не только эти три утилитки  
используют hal.. А как же Xorg? Ведь hal - это не только монтирование  
съемных дисков.. И т.д. и т.п.

Интересно все это..

Прошу прощения за кросс-пост.


-- 
С уважением,
Владимир Гусев

Re: [Comm] [Antique] Развитие tray_eject

[Mikhail Efremov]

On Sun, 26 Sep 2010 23:17:00 +0400
Владимир Гусев wrote:

> Да, слухи о кончине hal как-то невзначай пробегали в рассылке.. Чем
> это грозит для обычных прикладных программ, вполне ясно из вашего
> письма.. Мне непонятно лишь одно - да, в этом случае нам повезло,
> есть Юра, с котором можно легко обсудить проблему. Но ведь не только
> эти три утилитки используют hal.. А как же Xorg? Ведь hal - это не
> только монтирование съемных дисков.. И т.д. и т.п.

Я не в курсе о чем тут речь, но HAL действительно мертв, AFAIK. В
большинстве программ, имеющих живой апстрим, поддержку HAL уже
выкинули. Тот же xorg в Сизифе hal не использует.

-- 
WBR, Mikhail Efremov

Re: [Comm] [Antique] Развитие tray_eject

[Владимир Гусев]

>> Да, слухи о кончине hal как-то невзначай пробегали в рассылке.. Чем
>> это грозит для обычных прикладных программ, вполне ясно из вашего
>> письма.. Мне непонятно лишь одно - да, в этом случае нам повезло,
>> есть Юра, с котором можно легко обсудить проблему. Но ведь не только
>> эти три утилитки используют hal.. А как же Xorg? Ведь hal - это не
>> только монтирование съемных дисков.. И т.д. и т.п.
>
> Я не в курсе о чем тут речь, но HAL действительно мертв, AFAIK. В
> большинстве программ, имеющих живой апстрим, поддержку HAL уже
> выкинули. Тот же xorg в Сизифе hal не использует.

Xorg - большой и важный пакет, его будут спасать и модернизировать всеми  
силами, а вот сколько мелких но полезных вещиц пропадет... и пока  
"народятся" новые, мы будет в этой временной дыре - старое уже не годится,  
а нового еще нет.
Речь о сегодняшнем дне, о том, на что опираться проектам, в данном случае  
Antique. Пока у нас есть бранч 5.1, а когда будет новый срез - неизвестно.  
В 5.1 эти новшества вряд ли попадут. Поэтому я предлагаю пока заниматься  
тем, что есть на данный момент, не распыляться, но быть начеку.

Вот и все мое мнение? Я не прав?

-- 
С уважением,
Владимир Гусев

Re: [Comm] [Antique] Развитие tray_eject

[Радик Юсупов]

  On 27.09.2010 02:18, Владимир Гусев wrote:
>
> Xorg - большой и важный пакет, его будут спасать и модернизировать 
> всеми силами, а вот сколько мелких но полезных вещиц пропадет... и 
> пока "народятся" новые, мы будет в этой временной дыре - старое уже не 
> годится, а нового еще нет.
> Речь о сегодняшнем дне, о том, на что опираться проектам, в данном 
> случае Antique. Пока у нас есть бранч 5.1, а когда будет новый срез - 
> неизвестно. В 5.1 эти новшества вряд ли попадут. Поэтому я предлагаю 
> пока заниматься тем, что есть на данный момент, не распыляться, но 
> быть начеку.
>
> Вот и все мое мнение? Я не прав?
Вы правы, Владимир.
Но даже в случае с 5.1 можно подготовится. Например, перестать 
использовать pcmanfm как файловый менеджер и переполсти на pcmanfm2, в 
котором уже выкинут hal и используется udisks. Скорее всего из сизифа 
первый будет выкинут, но в 5.1 останется.
В случае с tray_eject_plus, можно разрабатывать его в рамках 5.1 и ждать 
того что придумает gns@, а потом использовать для себя. Правда есть 
вариант, что gns@ напишет его сразу на gtk, поэтому возможно имеет смысл 
Юре связаться с ним и уже совместно что-то сделать для того, чтобы в 
новом бранче уже знать что к чему и не изобретать новую монтировалку, а 
доработать старую.
Собственно pcmanfm и сам монтирует и размонтирует диски...но хочется 
значка в трее ;)

-- 
Ведущий инженер ООО "Центр"
ALTLinux Team
Jabber: radyus@jabber.ru

Re: [Comm] [Antique] Развитие tray_eject

[Владимир Гусев]

>> Xorg - большой и важный пакет, его будут спасать и модернизировать  
>> всеми силами, а вот сколько мелких но полезных вещиц пропадет... и пока  
>> "народятся" новые, мы будет в этой временной дыре - старое уже не  
>> годится, а нового еще нет.
>> Речь о сегодняшнем дне, о том, на что опираться проектам, в данном  
>> случае Antique. Пока у нас есть бранч 5.1, а когда будет новый срез -  
>> неизвестно. В 5.1 эти новшества вряд ли попадут. Поэтому я предлагаю  
>> пока заниматься тем, что есть на данный момент, не распыляться, но быть  
>> начеку.
>>
>> Вот и все мое мнение. Я не прав?
> Вы правы, Владимир.
> Но даже в случае с 5.1 можно подготовится. Например, перестать  
> использовать pcmanfm как файловый менеджер и переполсти на pcmanfm2, в  
> котором уже выкинут hal и используется udisks. Скорее всего из сизифа  
> первый будет выкинут, но в 5.1 останется.

Я настаивал на первом pcmanfm только из-за особой падучести pcmanfm2 (по  
крайней мере месяца 2 назад было именно так - сырость и  
недоработанность).. Кстати я не нашел по apt-cache search упоминаний про  
udisks, за исключением qmmp-udisks.. Это выделено в виде пакета, или  
каким-то образом включено в ядро в виде модуля?

> В случае с tray_eject_plus, можно разрабатывать его в рамках 5.1 и ждать  
> того что придумает gns@, а потом использовать для себя. Правда есть  
> вариант, что gns@ напишет его сразу на gtk, поэтому возможно имеет смысл  
> Юре связаться с ним и уже совместно что-то сделать для того, чтобы в  
> новом бранче уже знать что к чему и не изобретать новую монтировалку, а  
> доработать старую.

Можно подсмотреть, а создавать все же свое. Конечно многое зависит от  
качества и продуманности утилиты от gns@.. Хочу также добавить, что gtk2 в  
нашем случае (Antique) не устроит - утилита будет довольно ресурсоемкой..  
Собственно толчком к созданию tray_eject_plus стал непомерный аппетит  
qtrayvolman (который на qt4)

> Собственно pcmanfm и сам монтирует и размонтирует диски...но хочется  
> значка в трее ;)

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


-- 
С уважением,
Владимир Гусев

Re: [Comm] [Antique] Развитие tray_eject

[Mikhail Efremov]

On Mon, 27 Sep 2010 02:18:18 +0400 Владимир Гусев wrote:
> >> Да, слухи о кончине hal как-то невзначай пробегали в рассылке.. 
> > Я не в курсе о чем тут речь, но HAL действительно мертв, AFAIK. В
> > большинстве программ, имеющих живой апстрим, поддержку HAL уже
> > выкинули. Тот же xorg в Сизифе hal не использует.
> 
> Xorg - большой и важный пакет, его будут спасать и модернизировать
> всеми силами, а вот сколько мелких но полезных вещиц пропадет... и
> пока "народятся" новые, мы будет в этой временной дыре - старое уже
> не годится, а нового еще нет.

У "мелких и полезных вещиц" должен быть живой астрим, который должен о
них позаботиться, иначе они умрут вместе с hal. Куда им и дорога, если
живого апстрима у них нет.
Агония hal'а будет продолжаться еще некоторое время, конечно, и будут
еще поддерживаться старые версии программ в расчете на hal (например, в
NetworkManager в ветке 0.7.x hal используется и использоваться будет и
дальше). Но надо учитывать, что это уже legacy, и писать что-то новое,
ориентируюсь на умерший hal мне кажется странным. Это все равно
придется переделывать, если предполагается, что программа будет
развиваться и дальше.

> Речь о сегодняшнем дне, о том, на что опираться проектам, в данном
> случае Antique. Пока у нас есть бранч 5.1, а когда будет новый срез -
> неизвестно. В 5.1 эти новшества вряд ли попадут. Поэтому я предлагаю
> пока заниматься тем, что есть на данный момент, не распыляться, но
> быть начеку.

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

-- 
WBR, Mikhail Efremov