[Дизайн пользовательского интерфейса Головача] Очень старая книга (2001-2003), которая удивительно хорошо рассказывает про проектирование и вообще основы юзабилити. Рекомендую её читать в обязательном порядке. Единственный момент – автор, внезапно, написал вторую книгу с таким же названием, и она больше про GTD и всякие побочные вещи. Поэтому крайне важно найти именно первую часть.
Забавно, что сам автор при этом пишет, что вторая книга «гораздо лучше», и первая «уже не кажется [ему] удовлетворительной». Первая часть, к слову, вышла чуть раньше 2001 г. — в октябре двухтысячного года (опять же, со слов автора по ссылке).
Application Security имел на салфетках много zero days, написанных про базы данных Oracle. [...] И баги, которые находятся в этих базах данных, они там сидят по два-три года после того, как какой-нибудь security researcher их нашел. Вроде бы все чувствуют себя лучше, потому что не знают об этих проблемах. [...]
Вот это удивительно просто: знать про зиродеи (внутри компании) и не исправлять их годами!
Я не являюсь вашим лицензионным пользователем, и не имею никакого права требовать что-то от вашего саппорта. Мне интересен ваш продукт, но прежде чем говорить с руководством о перспективах приобретения, мне нужно будет не то что доказать, что покупка оправдана, но хотя бы продемонстрировать возможность запуска не-из-под Windows. Увы, сделать этого я не могу.
Кроме того, даже если бы я был лицензионным пользователем, нет никаких гарантий, что вы не ответите «извините, мы не обещали работу в Wine; вы же покупали версию для Windows? Там (нативно) всё работает? Ну вот видите, а наша (и ваша) поддержка распространяется исключительно на неё».
И последнее: имхо, «в абсолютно рабочем порядке такие доработки» обычно делаются просто потому, что неработающая в Wine user-space программа это странно: либо баг в программе (значит, надо пофиксить), либо в Wine (хорошо бы заслать bug report). В конце-концов, ведь для того, чтобы зарепортить проблему в публичной, ознакомительной версии, не должна требоваться покупка, правда?
В китайских системах ввода можно регулировать начертание и ширину для пунктуации и символов латиницы. Вот, например, как может выглядеть floating-окошко в режиме ввода иероглифов (можно временно переключиться на латиницу, нажав правый Shift):
Видите полумесяц и «прозрачную» точку с запятой? В режиме «полнолуния» (широкие символы, соответственно ширине иероглифа) точка и запятая переключает вид знаков «китайской» пунктуации, например: 。，、vs. ．，＼. Вводимая в этом режиме латиница будет выглядеть так: ＡＢＣ.
На картинке приведена стандартная конфигурация: «точки-бублики» для китайского текста и «нормальная» ширина для латиницы и латинской пунктуации.
Хорошо это заметно у китайцев, они очень любят писать кириллицу шрифтом с засечками и с чудовищными межбуквенными интервалами.
У китайцев это связано с тем, что в самом распространенном и часто используемом шрифте (SimSun) именно такая ужасная кириллица (латиница немногим лучше, но хотя бы читаема).
Ну окей, проц с памятью я, в принципе, могу и отпаять при необходимости (и таки-да, здесь производителя можно понять — слоты и разъемы действительно больше места занимают). Но вот использование нестандартных интерфейсов/компонентов (пример: SSD в новых MBP) и замена винтиков клеем (повсеместно) — натуральное вредительство.
Да, это большая проблема с современными гаджетами вообще — они, как правило, неразбираемы, нерасширяемы и неремонтируемы. Распаянная память, BGA-процы, проприетарные (нестандартные) накопители; всё залито компаундом и посажено на клей. Грусть и печаль, хоть не апгрейдься совсем. :-(
Смысл, например, в том, чтобы проверять свой код PVS-студией, не устанавливая при этом Windows. Я не предлагаю «научить анализатор работать с linux‐специфичными вещами», пусть это будет моей головной болью — как бы так подсунуть свой код, чтобы PVS-студия его успешно проверила (посчитав вендовым). А вот ставить Windows и/или возиться с виртуалками я не хочу.
Да-да, вы мне так в январе и ответили, что нет спроса. Я, наверное, недостаточно четко выразился: речь не про Windows-версию, обернутую в Wine для непосредственного запуска в линуксе и готовую к проверке нативных проектов под Unix/Linux. Это как раз понятно, что большой труд, мало кому нужный одновременно.
Я лишь про то, чтобы допилить обычную Windows-версию для запуска под вайном (версия 5.21 вываливается с Internal Error: Invalid escape sequence: '\b'), чтобы проверять вендовые же проекты без необходимости устанавливать Windows. Эта задача, на мой взгляд, вполне решаема. Никакой специальной вайн-версии не появляется — просто ваша обычная вендовая версия начинает работать под вайном (ничего про Linux при этом не зная).
Уж если Photoshop CS2 вполне так работает, почему PVS-Studio не может? :-)
Побуду занудой (раз уж на комментарий выше мне так никто и не ответил) и снова вас спрошу: почему бы не сделать Windows-версию (которая вполне себе перспективная, и которую явно никто не собирается убивать) поддерживающей работу из-под Wine? На первый взгляд это кажется проще, чем разрабатывать consumer-grade версию для GNU/Linux, и хоть как-то обрадует не-Windows пользователей и (возможно) потенциальных новых клиентов вашего бизнеса.
Атомы той эпохи были действительно ужасны. :-) Но за последние годы они явно подтянулись, цитирую: Atom CPU from 2014 has the [OpenSSL] performance directly comparable to that of a full-blooded Xeon from 2007.
Например если в конструкторе LockNet перед new Network будет получение какого либо хендла который надо закрыть в деструкторе — то оппа можно получить системный лок ресурса.
Верно, получение хендла в конструкторе — это известная проблема, и элегантного решения, по большому счету, нет. Особенно если хендл получаешь от сторонней библиотеки, которая не бросает исключений, или это вообще системный вызов; тривиальный пример: open(2).
Хм, Stellarium показывает, что Меркурий в это время находился намного дальше от Солнца (если наблюдать с Земли). Возможно, эта точка — объект HIP 117887 (пульсирующая переменная звезда).
Присоединяюсь к вопросу. Еще в январе EvgeniyRyzhkov говорил, что ни линукс-, ни вайн-версию в ближайшее время ожидать не стоит, ибо нет спроса; и в FAQ у вас до сих пор висит ответ «к сожалению, нет, извините» по этому поводу.
JS до сих пор узконаправленный — он работает только в браузере. А можно напрямую к JS прикрутить код на C/C++? Разве только в рамках Qt. Тот же Python уделывает JS по широте возможностей, а Lua по простоте встраивания его и в него.
JS уже давно не только «браузерный»; есть легковесные, легко встраиваемые реализации (например, duktape), хотя Lua, конечно, встраивать проще (чтобы к duktape «прикрутить код на C/C++», нужно писать много boilerplate кода, который по-хорошему должен авто-генерироваться, по типу SWIG).
Но у Lua, при всех ее достоинствах, очень плохая compatibility track record — никогда нельзя быть уверенным, что ничего не сломается при изменении даже минорной версии — у JS с этим намного лучше.
Хм, а FLTK не подойдет? (Не уверен разве что за качество/полноту language bindings и декларативные средства описания гуя.)
1) Кроссплатформенность.
Unix/Linux (X11), Windows, OS X.
2) Должна быть возможность написать приложение полностью на скриптовом языке.
3) Это должен быть развитый язык общего назначения с широким набором библиотек. Т.е. я должен иметь возможность на этом скриптовом языке работать с файлами, и многое другое.
Вот здесь у них перечислены Tcl/Tk, Perl, Guile, Python, Ruby и др. Lua, правда, не упоминается.
4) Богатый набор стандартных виджетов, возможность легко создавать собственные — произвольного внешнего вида и поведения.
На мной вкус довольно богатый «из коробки», собственные создаются или наследуются легко и просто.
5) API должен быть лаконичным и простым, хорошо также иметь возможность описывать GUI декларативно (типа QML, Kivy language).
К API у меня нареканий нет; но декларативные средства (если не считать fluid) отсутствуют.
6) Графический редактор интерфейса (как Qt Designer).
FLUID, входит в поставку. Не такой продвинутый, как Qt Designer, конечно, но пользоваться можно.
8) Библиотека должна использовать OpenGL там, где это оправдано. (по данным Google больше 90% всех устройств поддерживают OpenGL ES 2.0)
Natively supports 3D graphics via OpenGL and its built-in GLUT emulation. Другое дело, что это все-таки скорее для кастомных виджетов.
7) Идентичный на всех платформах внешний вид.
9) Библиотека должна быть удобна в сборке и установке, иметь хорошую, регулярно обновляемую документацию. Она не должна быть избыточна (в той же Qt переписали почти все стандартные библиотеки C++).
10) Небольшой размер. Простое приложение с GUI не должно весить под 100 МБ.
11) Небольшое число зависимостей, как можно более распространённых и без жёсткой привязки к конкретной версии.
Кроме того, даже если бы я был лицензионным пользователем, нет никаких гарантий, что вы не ответите «извините, мы не обещали работу в Wine; вы же покупали версию для Windows? Там (нативно) всё работает? Ну вот видите, а наша (и ваша) поддержка распространяется исключительно на неё».
И последнее: имхо, «в абсолютно рабочем порядке такие доработки» обычно делаются просто потому, что неработающая в Wine user-space программа это странно: либо баг в программе (значит, надо пофиксить), либо в Wine (хорошо бы заслать bug report). В конце-концов, ведь для того, чтобы зарепортить проблему в публичной, ознакомительной версии, не должна требоваться покупка, правда?
Видите полумесяц и «прозрачную» точку с запятой? В режиме «полнолуния» (широкие символы, соответственно ширине иероглифа) точка и запятая переключает вид знаков «китайской» пунктуации, например: 。，、vs. ．，＼. Вводимая в этом режиме латиница будет выглядеть так: ＡＢＣ.
На картинке приведена стандартная конфигурация: «точки-бублики» для китайского текста и «нормальная» ширина для латиницы и латинской пунктуации.
Я лишь про то, чтобы допилить обычную Windows-версию для запуска под вайном (версия 5.21 вываливается с Internal Error: Invalid escape sequence: '\b'), чтобы проверять вендовые же проекты без необходимости устанавливать Windows. Эта задача, на мой взгляд, вполне решаема. Никакой специальной вайн-версии не появляется — просто ваша обычная вендовая версия начинает работать под вайном (ничего про Linux при этом не зная).
Уж если Photoshop CS2 вполне так работает, почему PVS-Studio не может? :-)
open(2).Но у Lua, при всех ее достоинствах, очень плохая compatibility track record — никогда нельзя быть уверенным, что ничего не сломается при изменении даже минорной версии — у JS с этим намного лучше.
Unix/Linux (X11), Windows, OS X.
Вот здесь у них перечислены Tcl/Tk, Perl, Guile, Python, Ruby и др. Lua, правда, не упоминается.
На мной вкус довольно богатый «из коробки», собственные создаются или наследуются легко и просто.
К API у меня нареканий нет; но декларативные средства (если не считать fluid) отсутствуют.
FLUID, входит в поставку. Не такой продвинутый, как Qt Designer, конечно, но пользоваться можно.
Natively supports 3D graphics via OpenGL and its built-in GLUT emulation. Другое дело, что это все-таки скорее для кастомных виджетов.
Это все можно сказать про FLTK.