Тухлый Александр (0xd34df00d)

*leechcraft
А что, если вообще убрать тулбар и не показывать его, когда он не нужен? Это тот, в котором адресная строка у брауера, кнопки управления торрент-клиентом, и так далее?
Тогда табы будут наверху, прямо под титлбаром, а тулбар можно показывать при наведении на специальную область скраю таббара, например.

#1300998
from Azoth_primary, 4 months ago

← All messages

Replies (51)

Post a reply (xmpp)

@magog:
нет
#1300998/1
from Psi+, 4 months ago
@nya:
просто зделай хром
#1300998/2
from Home, 4 months ago
@0xd34df00d:
@magog Почему?
#1300998/3
from Azoth_primary, 4 months ago, in reply to /1
@0xd34df00d:
@nya Хрома не получится.
#1300998/4
from Azoth_primary, 4 months ago, in reply to /2
@magog:
@0xd34df00d потому что это уже есть
#1300998/6
from Psi+, 4 months ago, in reply to /3
@0xd34df00d:
@azcapone Расшифруй.
#1300998/7
from Azoth_primary, 4 months ago, in reply to /5
@0xd34df00d:
@magog Только в фуллскрине, да и то немножко косячно. А я не про фуллскрин, ибо мало кто юзает личкрафты в фуллскрине, даже я не юзаю их в фуллскрине.
#1300998/8
from Azoth_primary, 4 months ago, in reply to /6
@magog:
@0xd34df00d то, что ты предлагаешь и есть фулскрин
#1300998/9
from Psi+, 4 months ago, in reply to /8
@magog:
@magog только меню титлбар не убирается
#1300998/10
from Psi+, 4 months ago, in reply to /9
@0xd34df00d:
@magog Нет же. Это позволит мне иметь совсем другую концепцию менюшечек.
#1300998/11
from Azoth_primary, 4 months ago, in reply to /9
@magog:
@magog короче говно идея. Не хвататло мне еще мышкой двигать для попадания в адресную строку
#1300998/12
from Psi+, 4 months ago, in reply to /9
@0xd34df00d:
@magog А так ты ей не двигаешь?
#1300998/13
from Azoth_primary, 4 months ago, in reply to /12
@gelraen:
не лезь руками к GUI
#1300998/14
from imax, 4 months ago
@magog:
@gelraen это точно. Уже слазил — до сих пор ни один дизайнер не берется переделать
#1300998/16
from Psi+, 4 months ago, in reply to /14
@folex:
Тогда я буду много блевать.
#1300998/17
from mcabber_pc, 4 months ago
@magog:
@folex аналогично
#1300998/18
from Psi+, 4 months ago, in reply to /17
@0xd34df00d:
@azcapone А что делать-то?
#1300998/19
from Azoth_primary, 4 months ago, in reply to /15
@0xd34df00d:
@gelraen Окей, а как? Народ давно предлагает вынести кнопку меню в таббар, а остальной тулбар куда-нибудь запрятать, например. У меня ДЖВА ЛАГЕРЯ что ли пользователей?
#1300998/20
from Azoth_primary, 4 months ago, in reply to /14
@magog:
@0xd34df00d у тебя нету пользователей. Они все хотят просто побыстрее убить личкрафты
#1300998/21
from Psi+, 4 months ago, in reply to /20
@gelraen:
@0xd34df00d я не пользователь даже :$
#1300998/22
from imax, 4 months ago, in reply to /20
@folex:
@0xd34df00d может ты СДЕЛАЕШЬ ГАЛОЧКУ, КОТОРОЙ ЭТО ВКЛЮЧАЕТСЯ/ВЫКЛЮЧАЕТСЯ?
#1300998/23
from mcabber_pc, 4 months ago, in reply to /20
@0xd34df00d:
@gelraen Это временно^U А зря :3
#1300998/24
from Azoth_primary, 4 months ago, in reply to /22
@0xd34df00d:
@magog И они за мной следят.
#1300998/25
from Azoth_primary, 4 months ago, in reply to /21
@0xd34df00d:
@azcapone Если ты за три года общения со мной еще не понял, что я не умею думать со стороны пользователя, просто физически не умею, то это печально.
#1300998/27
from Azoth_primary, 4 months ago, in reply to /26
@gelraen:
@folex кстати да, я давно матерю дывелоперов KDE, которые перепилюват всё в говно и не делают галочку "сделать как было раньше". Хотя я матерю всех кто не делает галочку "сделать как было раньше"
#1300998/28
from imax, 4 months ago, in reply to /23
@0xd34df00d:
@folex Там нужно весьма радикально перепиливать GUI-нутро для этого, заебешься поддерживать оба варианта.
#1300998/29
from Azoth_primary, 4 months ago, in reply to /23
@magog:
@azcapone cli+gui — не подходит для такого приложения
#1300998/31
from Psi+, 4 months ago, in reply to /30
@0xd34df00d:
@azcapone Во времена вывода юникс-вея гуями даже не пахло.
Невозможно построить вменяемое и юзабельное разделение на GUI-frontend && CLI-backend для такого приложения. Либо это придется запихивать в каждый плагин (и я посмотрю на CLI браузера, да), либо делать обобщенный протокол на произвольном markup language — welcome тормоза, Core i7 будет минимальной требуемой конфигурацией.
#1300998/33
from Azoth_primary, 4 months ago, in reply to /30
@magog:
@azcapone годная мысль. Я только за. Но один хуй на наше мнение всем ^W дудфуд похуй
#1300998/35
from Psi+, 4 months ago, in reply to /34
@0xd34df00d:
@azcapone Да без разницы, все равно либо протокол городить, либо городить это в явном виде в каждом плагине, и каждый плагин разделять таким образом на две части. Первое — тормоза пиздец (формировать пакетики в абстрактнейшем протоколе на каждый чих и на каждое проведение мышкой над виджетом и гонять туда-сюда пусть даже по IPC), второе — просто пиздец.
#1300998/36
from Azoth_primary, 4 months ago, in reply to /34
@0xd34df00d:
@magog Ничерта она не годная. Попробуй подумать над реализацией. А то аналитиками с лора пахнет, чесное слово.
#1300998/37
from Azoth_primary, 4 months ago, in reply to /35
@magog:
@0xd34df00d да тебе все равно бестолку доказывать. Так что похуй
#1300998/38
from Psi+, 4 months ago, in reply to /37
@0xd34df00d:
@magog Я не прошу мне доказывать, я прошу подумать над возможными путями реализации.
#1300998/39
from Azoth_primary, 4 months ago, in reply to /38
@magog:
@0xd34df00d в чем проблема излучения соответсвутющих сигналов из гуи в engine и обратно?
#1300998/40
from Psi+, 4 months ago, in reply to /39
@0xd34df00d:
@magog В том, что они, для начала, в разных процессах. Значит, тебе надо инкапсулировать все это каким-либо образом в весьма узкий спектр примитивных типов данных, которые могут передаваться между процессами. Кроме того, тебе либо надо учитывать такую возможность в каждом плагине (== ооооочень дохуя кода даже для примитивных плагинов, если я на хаскеле все это перепишу, будет больше шансов найти контрибьюторов), либо пусть этим всем заведует ядро, но тогда оно должно обмениваться информацией о тех сущностях, о которых оно заранее не знает => обмениваться надо на весьма низкоуровневом свободном от семантики протоколе, тем не менее, на котором придется эту семантику выражать.
Делай выводы.
#1300998/41
from Azoth_primary, 4 months ago, in reply to /40
@magog:
@0xd34df00d вот как-то VBox же работает? И еще over 9000 софта. Как они работают?
#1300998/42
from Psi+, 4 months ago, in reply to /41
@0xd34df00d:
@magog У них фронтенд знает о всей семантике бекенда, and vice versa. В терминах личкрафтов это первый вариант.
Подумай, ну пзязя, ну я верю, у тебя получится понять, что когда все реализуют плагины, о которых ядро не знает, то это далеко не то же самое, как если бы ядро знало о всех виджетах/сигналах/данных плагинов.

Блять, ну это такие очевидные вещи, что я не знаю, как их объяснить.
#1300998/43
from Azoth_primary, 4 months ago, in reply to /42
@folex:
@0xd34df00d А что, никак нельзя сделать так, что бы ядро узнавало о плагине, когда тот подключался? Или нельзя никак достигнуть нужной степени "узнаваемости"?
#1300998/44
from mcabber_pc, 4 months ago, in reply to /43
@0xd34df00d:
@folex Я еще не придумал ИИ на лиспе.
Достигнуть это можно — разделяя каждый плагин напрямую руками на фронтенд и бекенд. Но это довольно быстро станет неуправляемым пиздецом.
#1300998/45
from Azoth_primary, 4 months ago, in reply to /44
@folex:
@0xd34df00d То есть количество информации, которое нужно знать ядру о плагине настолько велико, что придется лепить целый backend? Или всё же оно не так уж и велико, и это вполне можно включить в условие включения плагина в оф. релиз?
#1300998/46
from mcabber_pc, 4 months ago, in reply to /45
@0xd34df00d:
@folex А, ты предлагаешь хардкодить информацию о плагине в ядро?
#1300998/47
from Azoth_primary, 4 months ago, in reply to /46
@folex:
@0xd34df00d ШТОНЕТ. Наоборот же. Хотя, идея тоже ничотак, срсли. То есть если вы хотите полностью реализовать функционал системы плагинов LC в своем плагине, то вы должны попасть в оф. релиз. Что пока что не так уж и сложно, тащем.
#1300998/48
from mcabber_pc, 4 months ago, in reply to /47
@0xd34df00d:
@folex Окей, не хардкодить.
Я предлагаю решение подобное — весьма лоу-левел markup language для интерфейсов и событий, based on YAML или XML. А теперь подумай, как быстро это будет работать.

Олсо,

если вы хотите полностью реализовать функционал системы плагинов LC в своем плагине, то вы должны попасть в оф. релиз
нихуя не понял.
#1300998/49
from Azoth_primary, 4 months ago, in reply to /48
@folex:
@folex Я имел ввиду всё то же разделение, просто хотел сказать, что быть может всё не так страшно и не будет огромного фронтэнда и огромного бэкэнда? А будет плагин и немного служебной информации, которую и будет читать откуда-нибудь ядро. Или точно придется разделять плагин на огромные куски?
#1300998/50
from mcabber_pc, 4 months ago, in reply to /48
@0xd34df00d:
@folex Либо разделять на куски, либо пилить abstract UI/events markup language.
#1300998/51
from Azoth_primary, 4 months ago, in reply to /50
@folex:
@0xd34df00d Ну да, это будет работать медленно, НО сколько раз это должно будет отработать? ОДИН? Смотри, мы разобрали код на некотором markup language, превратили его в понятный для ядра формат, так?
#1300998/52
from mcabber_pc, 4 months ago, in reply to /49
@folex:
@folex Так вот, если это так, то почему бы нам не СОХРАНИТЬ это в понятном для ядра формате, а не парсить каждый раз в рантайме?
#1300998/53
from mcabber_pc, 4 months ago, in reply to /52
@0xd34df00d:
@folex Не так. Постоянно, при каждом событии, гонять пакетики в этом ML от фронтенда к (ядру+плагин) и обратно.
#1300998/54
from Azoth_primary, 4 months ago, in reply to /52
@folex:
@0xd34df00d тогда хардкодить
#1300998/55
from mcabber_pc, 4 months ago, in reply to /54
@0xd34df00d:
@folex Вооооот. Нет пути.
#1300998/56
from Azoth_primary, 4 months ago, in reply to /55
@A-i-D:
если так делать, то можно добавить возможность их фиксации, чтобы оставались только избранные
#1300998/57
from Переноска, 4 months ago

Тухлый Александр (0xd34df00d)

Subscribe

Replies (51)

Messages

Tags all

Search

Statistics