Замечено, что на mac'е он значительно лучше работает. Собственно, на mac для простых операций и просмотра истории я использую старую версию Source Tree со старым дизайном, для всего остального — консоль. А вот под Win приходится использовать git как есть.
Это, кстати, тоже всеобщая тенденция. Atlasian со своим Source Tree такой де фигнёй страдает.
Можете оценить прямо на их сайте: https://www.sourcetreeapp.com/
Верхний скрин — текущая версия, все остальные — из предыдущих версий
Переключитесь на тему «фантазия», она не настолько ужасна. Но она багованая… глючит переключение фона. Чтобы переключение фона отключить — нужно нажать кнопку слева внизу.
А самое главное, что мне это убожество включила техподдержка, когда я попытался зарепортить баг в старом интерфейсе, при том что в тикет была включена просьба НЕ переключать интерфейс. Отключать же не хотят. EugeneNikelsen, как вы думаете, что я думаю о вашей поддержке? Вы о такой штуке, как лояльность клиентов, случайно, не слышали?
У меня, как у пользователя, есть болишье личные претензии к вашим гайдлайнам: они сжирают место на экране, при этом неочевидно скрывают функционал и описания, а видимой сетки, за которую мог бы зацепиться глаз при поиске и разделении блоков — просто нет.
Собственно, этом страдают все ваши «обновлённые» продукты.
… а можно не использовать сдвиг и не иметь таких проблем. Альтернативных решений много, нужно выбрать только не съедающие быстродействие вашего сервиса.
Но у нас же ещё есть гравитация, гироскопический эффект и ещё много чего. Так же сами написали, что мы не можем получить локального минимума, не добавив заряд в точку. Но заряд-то добавить мы можем, при этом сместив точку равновесия гравитацией, освободив тем самым току равновесия от материального объекта.
К тому же в сети есть видео стабильной левитации магнита с использоватием магнитных свойств висмута:
https://www.youtube.com/watch?v=A5pZZJ23rDM
В многих лицензиях МС к бесплатным продуктам есть пункт о том, что запускать эти продукты вы можете только на системе с лицензионной Windows. В либах msvb такого условия нет?
Ну, как уже выяснилось в соседней метке — IB видит в том числе и свойства, объявленные в категориях.
По поводу UIButton: я работаю с платформой начиная с iPhone OS 3.1.3, и не разу не замечал у UIButton признаков кластера, в отличии от того же NSArray. Возможно — я был недостаточно внимателен. Возможно — вы что-то путаете.
По поводу наследования: не вижу ни одного повода от него отказываться — это основная концепция ООП.
К тому же нужно всего лишь следить за отсутствием конфликтов имён и не использовать приватные методы. Для того, чтобы при таком подходе что-то сломалось — Эппл должен переписать половину SDK, по пути сломав половину приложений из AppStore. Этого не случится никогда.
Отличить кластер можно по возвращаему типу, не совпадающему с оригинальным. Для [NSArray array], например, это __NSArray0.
Конструкторы UIButton возвращает всегда UIButton. Так что даже если там внутри происходит какая-то «магия» — на наследование она не влияет.
> Но сабклассить его всё равно не стоит
В эппловской документации для таких классов содержится отдельное предупреждение (как, например, у UIWebView: «Subclassing Notes: The UIWebView class should not be subclassed.»)
В случае же кнопки — некоторые вещи просто невозможно реализовать без наследования (модификация intrinsicContentSize, например)
Вашу идею, кстати, я тоже реализовывал, до того как нашёл способ добавить свойство в Interface Builder.
Там есть некоторые трудности с тем, что для некоторых контролов текст может быть выставлен для любых состояний (всех сочетаний получается 16 штук), причём непонятно, какие из них действительно выставлены.
С другой стороны, если у вас для разных состояний тексты действительно отличаются — возможно лучше использовать именно этот путь.
Вообще, я так запихиваю через Interface Builder многие вещи: шрифт из пресета, цвет placeholder'а у UITextField (который по умолчанию серый и не меняется в визуальном дизайнере), угол скругления, кастомный стиль кнопки и т.д. Практически всё, что обычно вручную делается в awakeFromNib можно реализовать таким образом.
Точно не скажу с какой версии, но сейчас в языке есть дерективы nullable и nonnull для аргументов и возвращаемых значений функций. На Swift я ещё не писал, но по описанию — похоже.
Вообще, сейчас в язык добавили много операторов-подсказок для компилятора, вроде NS_REQUIRES_NIL_TERMINATION.
Можете оценить прямо на их сайте: https://www.sourcetreeapp.com/
Верхний скрин — текущая версия, все остальные — из предыдущих версий
https://yadi.sk/i/BaXEzQsrwPHeW
Фильтр по производителям Яндекс.Маркета.
Задача 1: Найти производителя GoodRam
задача 2: Понять, как этот фильтр отсортирован
А самое главное, что мне это убожество включила техподдержка, когда я попытался зарепортить баг в старом интерфейсе, при том что в тикет была включена просьба НЕ переключать интерфейс. Отключать же не хотят. EugeneNikelsen, как вы думаете, что я думаю о вашей поддержке? Вы о такой штуке, как лояльность клиентов, случайно, не слышали?
Собственно, этом страдают все ваши «обновлённые» продукты.
К тому же в сети есть видео стабильной левитации магнита с использоватием магнитных свойств висмута:
https://www.youtube.com/watch?v=A5pZZJ23rDM
По поводу UIButton: я работаю с платформой начиная с iPhone OS 3.1.3, и не разу не замечал у UIButton признаков кластера, в отличии от того же NSArray. Возможно — я был недостаточно внимателен. Возможно — вы что-то путаете.
По поводу наследования: не вижу ни одного повода от него отказываться — это основная концепция ООП.
К тому же нужно всего лишь следить за отсутствием конфликтов имён и не использовать приватные методы. Для того, чтобы при таком подходе что-то сломалось — Эппл должен переписать половину SDK, по пути сломав половину приложений из AppStore. Этого не случится никогда.
Конструкторы UIButton возвращает всегда UIButton. Так что даже если там внутри происходит какая-то «магия» — на наследование она не влияет.
> Но сабклассить его всё равно не стоит
В эппловской документации для таких классов содержится отдельное предупреждение (как, например, у UIWebView: «Subclassing Notes: The UIWebView class should not be subclassed.»)
В случае же кнопки — некоторые вещи просто невозможно реализовать без наследования (модификация intrinsicContentSize, например)
Там есть некоторые трудности с тем, что для некоторых контролов текст может быть выставлен для любых состояний (всех сочетаний получается 16 штук), причём непонятно, какие из них действительно выставлены.
С другой стороны, если у вас для разных состояний тексты действительно отличаются — возможно лучше использовать именно этот путь.
При локализация ксибов я использую такой подход:
Для интерфейстых элементов создаю собственные сабклассы со свойством
В сеттере которого присваиваю текст, полученный из NSLocalizedString по присвоенному по свойству ключу.
Это свойство видно в Interface Builder, в него и нужно прописать ключ локализации.
Вообще, сейчас в язык добавили много операторов-подсказок для компилятора, вроде NS_REQUIRES_NIL_TERMINATION.