Меня искренне удивляет почему разработчики больше не занимаються разработкой Fullscreen для Snow Leopard. Разве это не возможно сделать без нового API? — конечно возможно, но почему-то это не считаеться нормальным порядком вещей.
The tone and language we use is straightforward and conversational. This means we avoid engineering terms, overly technical words, obscure acronyms and industry jargon.
When writing copy for your app, always ensure it's as friendly and natural as possible. One way to achieve this is to read your copy out loud.
Don't Use: «Unable to open Gallery»
Use: «The Gallery won’t open»
Don't Use: «Verify settings»
Use: «Now check your settings»
Don't Use: «Synchronize your calendar with the device»
Use: «Sync your calendar»
Первая проблема — digits может использоваться не только этим потоком. Модуль simple_thread позволяет обойти эту проблему. Когда мы получаем атрибут, нам возвращается не ссылка на этот атрибут, а его копия. При этом, все действия происходят в контексте основного потока, и нам не надо беспокоиться об одновременном доступе к атрибуту из нескольких потоков.
В CPython такой проблемы нет — благодаря GIL в любой момент времени исполняеться только один поток. То есть можно не особо задумываясь обмениваться данными с стандартными python-объектами посредством атрибутов. Может возникнуть неожиданное поведение с Qt-объектами и это приводит нас к тому что:
Такой код не совсем Qt-friendly. Намного более идиоматичный вариант — сделать свой поток с сигналом textChanged(str) и присоиденить его соответствующему слоту — setText с помощью Qt::QueuedConnection соединения. Кода это особо не прибавит, а читать это потом будет намного легче. Кроме того если возникнет желание можно будет переписать такие потоки на С++.
Не нужно будет заморачиваться с установкой и настройкой, но зато прийдеться скомпилировать всю Qt из изходников, что может занять достаточно долгое время (около часа на i5-750 @2.66).
Также имейте ввиду, что стандартно macports компилирует все под x86_64, если есть такая возможность. Это привод к слегка большему размеру чем i386. Мне кажется самым простым вариантом еще добавлять вариант +universal при установке:
$ sudo port install py27-pyside +universal
и вырезать x86_64 из конечного .app — a с помощью:
#!/bin/sh
for i in `find dist/app.app/ -name *.so; find dist/app.app/ -name *.dylib`;
do
lipo $i -thin i386 -o $i;
done
Кроме того для уменьшение размера есть интересный инструмент, который мне пока еще не довелось использовать — hatchet.
The latest FUD is Microsoft’s claim that they won’t support WebGL because it’s insecure. They might have a little more credibility if they weren’t promoting a technology, Silverlight 5, that provides the EXACT SAME FEATURES with all the same issues. They can’t have it both ways. Either it’s possible to make this tech safe or else it’s not. If it is possible to make it safe in Silverlight 5 then it’s also just as possible in WebGL. If it’s not possible to make it safe Microsoft would have to come out and say (1) They are removing GPU access from Silverlight 5. (2) They are banning Unity3D from running in IE since it also provides access to the EXACT SAME FEATURES. (3) They are banning Flash 11 from running in IE since it also provides access to the EXACT SAME FEATURES.
Нихто ж вам не мешает разбивать ваш трафик на сколь угодно малые части и их потом отдельно сжимать/расжимать, не так ли? Не понятно на сколько менее оно будет еффетивно — но прикрутить вроде можно.
Оно использует компоненты iPhone SDK. Как только они появяться, что врядли, для других платформ — так сразу Моно Тач их станед поддерживать. А само Моно кроссплатформенно. ;)
Ну да, только для андроида действительно нативное приложение стандартными средствами не напишешь. Есть полунативные костыли в види NDK, но оно всеравно завязано на Java. Так что…
www.developer.nokia.com/swipe/ux/pages/Tone_and_Language.html
В CPython такой проблемы нет — благодаря GIL в любой момент времени исполняеться только один поток. То есть можно не особо задумываясь обмениваться данными с стандартными python-объектами посредством атрибутов. Может возникнуть неожиданное поведение с Qt-объектами и это приводит нас к тому что:
Такой код не совсем Qt-friendly. Намного более идиоматичный вариант — сделать свой поток с сигналом textChanged(str) и присоиденить его соответствующему слоту — setText с помощью Qt::QueuedConnection соединения. Кода это особо не прибавит, а читать это потом будет намного легче. Кроме того если возникнет желание можно будет переписать такие потоки на С++.
1. iPhone Application Development
2. Developing Apps for iOS
Не нужно будет заморачиваться с установкой и настройкой, но зато прийдеться скомпилировать всю Qt из изходников, что может занять достаточно долгое время (около часа на i5-750 @2.66).
Также имейте ввиду, что стандартно macports компилирует все под x86_64, если есть такая возможность. Это привод к слегка большему размеру чем i386. Мне кажется самым простым вариантом еще добавлять вариант +universal при установке:
и вырезать x86_64 из конечного .app — a с помощью:
Кроме того для уменьшение размера есть интересный инструмент, который мне пока еще не довелось использовать — hatchet.
Это они просто так обозвали екстеншены.
МюТоррент пошел по стопам ФайрФокса.
grab.by/yQy
(Safari 4.0.4, Mac OS X 10.6.2)