Я внёс большую часть изменений — можете попробовать новую версию (библиотеки по старым ссылкам уже обновлены). Остаётся разобраться с выборщиком файлов, но этим я уже займусь завтра на свежую голову :)
ежели редактор не планируется исключительно легковесным, можно добавить вместо/вместе с превью отдельные окошки для визуализации/тестов созданного 9-patch для различных элементов UI (Кнопки, текстбоксы, табы, ...). И соответственно генерировать xml стилей, чтобы сразу вставлять в свое android приложение.
Редактор скорее всего останется легковесным — подобной генерации xml-стилей под, непосредственно, Android не планировалось. Скажу даже больше — в дальнейшем возможности данной библиотеки будут использоваться для стилизации Swing-компонентов (уже используются, но пока-что эта версия ещё не выпущена). Поэтому не хочется привязывать утилиту ни к какому из направлений, а просто оставить более удобный и продвинутым nine-patch редактором.
Также мелочь конечно, но я уже очень долгое время не видел диалогов сохранения/открытия в виде, отличном от системного. У меня ярлычки ко всем важных местам на компьютере в стандартном диалоге, кастомный диалог очень усложняет пользователям жизнь ИМХО.
Это достаточно старая и холиварная тема. Проблема, во-первых, в том, что я не могу обеспечить нормальную работу нативных диалогов выбора на различных ОС. Если использовать свинговый выборщик — он также будет весьма далёк от нативного и ко всему прочему неудобен. Так что я твёрдо решил оставлять кросплатформенный вариант выборщика на кроссплатформенных приложениях — просто ему ещё требуется некоторое количество доработок и улучшений.
Ну и как уже упомянули — для тех кто скачал программу не по ссылке из этой статьи будет очень сложно сообразить как добавлять/таскать/удалять области. Подсказочку что ли какую нибудь бы.
Ну, тут без туториала сложно что-либо сделать — сыпать подсказками, как мне кажется, не выход. Будет слишком назойливо и раздражающе. Тем более я не собираюсь нигде выкладывать данное приложение/библиотеку без предварительного описания как в этой статье :)
Если есть какие-либо более конкретные мысли на этот счёт — буду рад выслушать
Собственно — он сделан действительно лучше двух других, но опять же не позволяет создавать несколько растягиваемых областей сразу. В остальном — заметил пару моментов, которые можно перенести в мой вариант редактора…
Ну и, кстати, вероятно в скором времени стоит сделать настройки приложения и вынести туда некоторые настройки редактора, которые сейчас просто всегда стоят по умолчанию.
Сначала подумал что нету масштабирования, но потом нашел его по Ctrl+колесо мыши. Об этом надо сообщать, а еще лучше продублировать кнопочками на панели, так же нету возможности уменьшить меньше оригинала (на случай большого исходника)
О зуме я даже отдельно написал в статье :)
Но на самом деле вы правы — просто был не самый удачный вариант слайдера на панели — я его временно убрал.
В следующей версии он вернётся в более опрятном виде и с подсказкой насчёт хоткеев.
Сохранение по Ctrl+S не добавляет автоматически к названию .9.png а сохраняет в оригинал
Я уже думал над тем — добавлять ли .9 при сохранении (если его, конечно, нет) или нет. Впринципе, думаю что стоит добавлять его по умолчанию — всё же ничего кроме nine-patch файлов сохранить из приложения не удастся же.
Диалог «Save As» нерабочий (хотелось бы, что бы когда заработает, сразу предлагал папку загруженной картинки, а не 'корень' диска)
Диалог сейчас вообще имеет ряд неприятных багов (не связанных с редактором), которые мне предстоит устранить в библиотеке — в т.ч. возможность ввода имени файла при сохранении и т.п.
Насчёт выбора исходной директории — согласен — исходно стоит показывать текущую директорию файла. Поправлю в ближайшем обновлении.
в превью хотелось бы попробовать многострочный текст тоже
Хм, идея конечно интересная, но не хочется пихать куда-либо в «лёгкий» диалог превью многострочное текстовое поле. Может просто стоит ввести некоторое обозначение переноса, которое можно использовать в поле? (например стандартный "\n" или же просто "\" или ";")
Думаю эти изменения внесу в ближайшее время и обновлю версию в статье :)
Спасибо за ссылку — не странно, что я не нашёл корейский сайт :)
Попробовал редактор — он не поддерживает более 1ой растягиваемой области, что зачастую весьма необходимо. Да и редактирование, как мне кажется, там не сильно удобнее чем в родном тулзе…
Всё же всегда очень хочется потаскать гайдлайны/область, а не двигать какие-либо отстранённые слайдеры и не рисовать попиксельно карандашом.
Кстати, раз уж вам известен ещё один редактор — не подбросите ссылку на его сайт/описание?
Я, честно говоря, так и не смог найти ни одного редактора помимо родного. Возможно просто схалтурил…
Мы скорее всего остановимся на первом варианте, который будет удовлетворять нашим требованиям к скорости и удобству использования. Хотя, если такового не найдётся в знакомых нам вариантах — будем копать дальше и искать новые.
В любом случае — спасибо, добавлю в список на «посмотреть».
У нас, скорее всего, будет первый вариант (мало передач на одного клиента в секунду).
На самом деле меня больше даже беспокоит то, с какой скоростью будут непосредственно передаваться данные — т.е. чтобы вовсе не возникало «очереди», которые напрямую могут влиять на скорость работы с приложением.
Впрочем, на разного качества каналах и на различных системах, как показывает практика, проблемы могут возникать либо с одноразовой передачей крупных данных, либо с постоянной отсылкой данных мелкими порциями, либо даже в обоих случаях у крайне тяжёлых «пациентов», так что, думаю, нам ещё только предстоит «увидеть врага в лицо» и узнать что лучше нам подойдёт.
Естественно экспериментов будет много, но всему есть предел. Поэтому подобные «информационные» статьи — когда всё что нужно для начала работы собрано в одном месте — на вес золота.
Если говорить более конкретно — по сути у нас будет происходить множество передач «мелких» данных вида:
Клиент1 -> Сервер -> Клиент2, Клиент3, Клиент4, Клиент5
С промежутком (в среднем) от 1 до 5-10 секунд между передачами.
Фактически это информирование об изменениях в одном клиенте всех других «слушающих» клиентов.
Плюс также будет некоторое количество отдельных специальных команд (авторизация, выход, передача настроек и пр. мелочей), отфильтровываемых и обрабатываемых сервером (впрочем этим уже будет заниматься «бизнес-логика»).
Сейчас действительно сложно сказать что будет более эффективно работать в качестве сервера — это ещё предстоит выяснить по результатам тестов.
Я уже достаточно долго (около 3-4 месяцев) нахожусь в раздумьях на тему того, как будет реализован будущий сервер приложения, которое должно в реальном времени синхронизировать данные между 2+ клиентами.
Это, конечно, не игровой сервер — максимальное предполагаемое число клиентов <100 (100 — только в страшном сне :), скорее обычно даже <10, но как мне кажется скоростью никогда не стоит пренебрегать. Да и по сути передаваемые данные будут схожи с игровыми действиями/командами — приведённая вами схема работы идеально ложится под наши задачи. Так что, думаю, благодаря вашей статье я начну первые тесты скорости и удобства использования именно с этого сервера.
Когда я вплотную возьмусь за работу с Netty возможно у меня будет пара-тройка конкретных вопросов по мелочам — тогда, если вы конечно не против, я задам вам их отдельно.
И большое спасибо за весьма полезную статью, коих встречается мало в последнее время :)
Где-то чуть меньше полугода использую схожую модель из другой линейки Asus (VX7) — по характеристикам он практически идентичен, только видео чуть слабее.
Во-первых — присоединяюсь к вопросуjetman:
Питание так же подключается справа и имеет неприятный 5-ти сантиметровый прямой коннектор, который мешает держать мышь в упор к ноутбуку. Также не очень радуют и кучи входов расположенные справа (USB/наушники/микрофон/HDMI). Так что присоединаяюсь к Вашему вопросу — отказались ли они от такого расположения портов/зарядки?
Во-вторых, хотелось бы добавить что…
Кроме неудобных входов, большого веса (это, впрочем, сполна покрывается отличной производительностью) и малого времени автономной работы (опять же, лучше я поработаю/поиграю час-два без лагов и тормозов, нежели наблюдать тупняки системы/приложений/игр) минусов лично я не замечал.
Опять же, насчёт веса — спокойно ношу ноутбук в отдельно купленном рюкзаке каждый день на работу и домой. От десктопов отказался ещё в далёком 2000-ом и при текущих возможностях ноутбуков не ощущаю нехватки производительности. Выходит намного проще и выгоднее держать одну мобильную «станцию», на которой можно делать всё что необходимо.
Кстати, я надеюсь до новогодних праздников выложить две достаточно масштабные статьи на тему — будет возможность оценить «силу» Swing и различные его возможности. Думаю по ним Вы сможете примерно прикинуть под какие цели лучше Swing, а под какие SWT.
Редактор скорее всего останется легковесным — подобной генерации xml-стилей под, непосредственно, Android не планировалось. Скажу даже больше — в дальнейшем возможности данной библиотеки будут использоваться для стилизации Swing-компонентов (уже используются, но пока-что эта версия ещё не выпущена). Поэтому не хочется привязывать утилиту ни к какому из направлений, а просто оставить более удобный и продвинутым nine-patch редактором.
Это достаточно старая и холиварная тема. Проблема, во-первых, в том, что я не могу обеспечить нормальную работу нативных диалогов выбора на различных ОС. Если использовать свинговый выборщик — он также будет весьма далёк от нативного и ко всему прочему неудобен. Так что я твёрдо решил оставлять кросплатформенный вариант выборщика на кроссплатформенных приложениях — просто ему ещё требуется некоторое количество доработок и улучшений.
Ну, тут без туториала сложно что-либо сделать — сыпать подсказками, как мне кажется, не выход. Будет слишком назойливо и раздражающе. Тем более я не собираюсь нигде выкладывать данное приложение/библиотеку без предварительного описания как в этой статье :)
Если есть какие-либо более конкретные мысли на этот счёт — буду рад выслушать
Ну и, кстати, вероятно в скором времени стоит сделать настройки приложения и вынести туда некоторые настройки редактора, которые сейчас просто всегда стоят по умолчанию.
Насчёт Тукса же — не знаю — видимо чем-то он насолил создателю библиотеки иконок.
О зуме я даже отдельно написал в статье :)
Но на самом деле вы правы — просто был не самый удачный вариант слайдера на панели — я его временно убрал.
В следующей версии он вернётся в более опрятном виде и с подсказкой насчёт хоткеев.
Я уже думал над тем — добавлять ли .9 при сохранении (если его, конечно, нет) или нет. Впринципе, думаю что стоит добавлять его по умолчанию — всё же ничего кроме nine-patch файлов сохранить из приложения не удастся же.
Диалог сейчас вообще имеет ряд неприятных багов (не связанных с редактором), которые мне предстоит устранить в библиотеке — в т.ч. возможность ввода имени файла при сохранении и т.п.
Насчёт выбора исходной директории — согласен — исходно стоит показывать текущую директорию файла. Поправлю в ближайшем обновлении.
Хм, идея конечно интересная, но не хочется пихать куда-либо в «лёгкий» диалог превью многострочное текстовое поле. Может просто стоит ввести некоторое обозначение переноса, которое можно использовать в поле? (например стандартный "\n" или же просто "\" или ";")
Думаю эти изменения внесу в ближайшее время и обновлю версию в статье :)
Попробовал редактор — он не поддерживает более 1ой растягиваемой области, что зачастую весьма необходимо. Да и редактирование, как мне кажется, там не сильно удобнее чем в родном тулзе…
Всё же всегда очень хочется потаскать гайдлайны/область, а не двигать какие-либо отстранённые слайдеры и не рисовать попиксельно карандашом.
Я, честно говоря, так и не смог найти ни одного редактора помимо родного. Возможно просто схалтурил…
Вот тут можно разом увидеть все иконки из набора.
В любом случае — спасибо, добавлю в список на «посмотреть».
Чтож, ещё раз спасибо за дельные советы :)
На самом деле меня больше даже беспокоит то, с какой скоростью будут непосредственно передаваться данные — т.е. чтобы вовсе не возникало «очереди», которые напрямую могут влиять на скорость работы с приложением.
Впрочем, на разного качества каналах и на различных системах, как показывает практика, проблемы могут возникать либо с одноразовой передачей крупных данных, либо с постоянной отсылкой данных мелкими порциями, либо даже в обоих случаях у крайне тяжёлых «пациентов», так что, думаю, нам ещё только предстоит «увидеть врага в лицо» и узнать что лучше нам подойдёт.
Если говорить более конкретно — по сути у нас будет происходить множество передач «мелких» данных вида:
Клиент1 -> Сервер -> Клиент2, Клиент3, Клиент4, Клиент5
С промежутком (в среднем) от 1 до 5-10 секунд между передачами.
Фактически это информирование об изменениях в одном клиенте всех других «слушающих» клиентов.
Плюс также будет некоторое количество отдельных специальных команд (авторизация, выход, передача настроек и пр. мелочей), отфильтровываемых и обрабатываемых сервером (впрочем этим уже будет заниматься «бизнес-логика»).
Сейчас действительно сложно сказать что будет более эффективно работать в качестве сервера — это ещё предстоит выяснить по результатам тестов.
Это, конечно, не игровой сервер — максимальное предполагаемое число клиентов <100 (100 — только в страшном сне :), скорее обычно даже <10, но как мне кажется скоростью никогда не стоит пренебрегать. Да и по сути передаваемые данные будут схожи с игровыми действиями/командами — приведённая вами схема работы идеально ложится под наши задачи. Так что, думаю, благодаря вашей статье я начну первые тесты скорости и удобства использования именно с этого сервера.
Когда я вплотную возьмусь за работу с Netty возможно у меня будет пара-тройка конкретных вопросов по мелочам — тогда, если вы конечно не против, я задам вам их отдельно.
И большое спасибо за весьма полезную статью, коих встречается мало в последнее время :)
Во-первых — присоединяюсь к вопросу jetman:
Питание так же подключается справа и имеет неприятный 5-ти сантиметровый прямой коннектор, который мешает держать мышь в упор к ноутбуку. Также не очень радуют и кучи входов расположенные справа (USB/наушники/микрофон/HDMI). Так что присоединаяюсь к Вашему вопросу — отказались ли они от такого расположения портов/зарядки?
Во-вторых, хотелось бы добавить что…
Кроме неудобных входов, большого веса (это, впрочем, сполна покрывается отличной производительностью) и малого времени автономной работы (опять же, лучше я поработаю/поиграю час-два без лагов и тормозов, нежели наблюдать тупняки системы/приложений/игр) минусов лично я не замечал.
Опять же, насчёт веса — спокойно ношу ноутбук в отдельно купленном рюкзаке каждый день на работу и домой. От десктопов отказался ещё в далёком 2000-ом и при текущих возможностях ноутбуков не ощущаю нехватки производительности. Выходит намного проще и выгоднее держать одну мобильную «станцию», на которой можно делать всё что необходимо.