хочу попробывать портировать софт для MacOS, покупать еще один ноут пока не хочеться.
Можно ли как-то под WMWare или другим способом установить MacOS на обычном компьютере с процессором Intel ?
Здравствуйте, maks1180, Вы писали: M>хочу попробывать портировать софт для MacOS, покупать еще один ноут пока не хочеться.
Скрытый текст
M>Можно ли как-то под WMWare или другим способом установить MacOS на обычном компьютере с процессором Intel ?
Запрещается публикация сообщений о поиске кряков, генераторов ключей, серийных номеров, нелицензионных объектов интеллектуальной собственности (программного обеспечения, книг, баз данных, медиапродукции), а также и предоставление подобной информации. Не приветствуются и ссылки на сайты подобного содержания.
Здравствуйте, 8bit, Вы писали:
8>Здравствуйте, maks1180, Вы писали:
8>Можно, ключевое слово hackintosh. 8>Я в свое время просто купил MacMini, он не дорогой.
Вы писали софт для MacOS ?
Интересно насколько сложно с Windows портировать С++ приложение.
M>Можно ли как-то под WMWare или другим способом установить MacOS на обычном компьютере с процессором Intel ?
можно найти образы под VMWare, но как тут уже посоветовали, лучше купить мак мини. можно б/у.
Здравствуйте, maks1180, Вы писали:
M>Интересно насколько сложно с Windows портировать С++ приложение.
Все зависит от того закладывали вы возможность портирования изначально или нет.
Если у вас нет прослойки между тем что приложение делает и платформенными вещами (ui и т.д),
то не очень просто, ну или по крайней мере не быстро.
LS>Запрещается публикация сообщений о поиске кряков, генераторов ключей, серийных номеров, нелицензионных объектов интеллектуальной собственности (программного обеспечения, книг, баз данных, медиапродукции), а также и предоставление подобной информации. Не приветствуются и ссылки на сайты подобного содержания.
Hackintosh не нарушает законов во многих странах. Так как является дополнением к _легально_ _купленной_ Mac OS.
Да, все обычное подходит, я только клавиатуру купил, понравилась.
На него же можно поставить и винду, в макос есть специальная функция для этого
и грузиться по выбору в любую операционку.
Б\У кстати тысяч за 15 можно взять.
Здравствуйте, maks1180, Вы писали:
M>Вы писали софт для MacOS ? M>Интересно насколько сложно с Windows портировать С++ приложение.
Смотря насколько оно на венду завязано. Если сразу писать на Qt и не использовать WIN32 API (по крайней мере, не использовать его без нужды и не размазывать по всей программе), то совсем несложно. Ну а если у вас там сплошной MFC и вызовы специфических виндовых функций повсюду через строчку, проче, наверное, с нуля переписать.
CRT>>обычный
8>Да, все обычное подходит, я только клавиатуру купил, понравилась. 8>На него же можно поставить и винду, в макос есть специальная функция для этого 8>и грузиться по выбору в любую операционку. 8>Б\У кстати тысяч за 15 можно взять.
Клавиатуру и мышку обычную можно подключить ?
Там винт от ноута или от стационарного ?
Процессор там от ноута или для стационарных ?
Сильно шумит, если его на ночь не выключать, будет ли слышно 2 метра от него ?
Здравствуйте, maks1180, Вы писали:
M>Клавиатуру и мышку обычную можно подключить ?
обычную M>Там винт от ноута или от стационарного ?
от ноута M>Процессор там от ноута или для стационарных ?
от ноута, наверно. коре2дуо M>Сильно шумит, если его на ночь не выключать, будет ли слышно 2 метра от него ?
у меня тишина полная даже ночью.
Здравствуйте, CRT, Вы писали:
CRT>Для Макинтоша родной язык это Objective-C CRT>плюс фреймворк Cocoa CRT>можно и на C++ писать но для Objective-C и Cocoa в разы больше информации
Не распространяй дезинформацию. Интерфейсный слой на Objective-C прекрасно сосуществует с кодом на С++, причём даже в одном файле можно писать на С++ и Objective-C (такая комбинация ещё называется Objective-C++).
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, CRT, Вы писали:
CRT>>Для Макинтоша родной язык это Objective-C CRT>>плюс фреймворк Cocoa CRT>>можно и на C++ писать но для Objective-C и Cocoa в разы больше информации C>Не распространяй дезинформацию. Интерфейсный слой на Objective-C прекрасно сосуществует с кодом на С++, причём даже в одном файле можно писать на С++ и Objective-C (такая комбинация ещё называется Objective-C++).
Здравствуйте, maks1180, Вы писали:
C>>Не распространяй дезинформацию. Интерфейсный слой на Objective-C прекрасно сосуществует с кодом на С++, причём даже в одном файле можно писать на С++ и Objective-C (такая комбинация ещё называется Objective-C++). M>Подскажите где API от MacOS можно посмотреть ? http://developer.apple.com/
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, CRT, Вы писали:
CRT>>Для Макинтоша родной язык это Objective-C CRT>>плюс фреймворк Cocoa CRT>>можно и на C++ писать но для Objective-C и Cocoa в разы больше информации C>Не распространяй дезинформацию. Интерфейсный слой на Objective-C прекрасно сосуществует с кодом на С++, причём даже в одном файле можно писать на С++ и Objective-C (такая комбинация ещё называется Objective-C++).
И в чем дезинформация? Человек хотел перенсти свое приложение на С++. Я сказал что придется еще изучать Objective-C и Cocoa чтобы хотя бы "интерфейсный слой" написать.
M>хочу попробывать портировать софт для MacOS, покупать еще один ноут пока не хочеться. M>Можно ли как-то под WMWare или другим способом установить MacOS на обычном компьютере с процессором Intel ?
Портирование софта будет относительно легким только в двух случаях:
— бОльшая часть кода является платформенно независимой, интерфейс четко отделен от бэкэнда
— софт напиcан с использованием кроссплатформанного фреймворка. Я знаю только один — Qt
В противном случае порт будет болезненным. Дело не в том что Cocoa плох, напротив, это очень качественный фреймворк. Придется переосмысливать дизайн приложения и писать вещи связанные с GUI на Objective-C/Cocoa.
PS Купить МакБук или Мини — не проблема, на этом компе будут работать как WinXP/Vista/7 так и MacOSX 10.5/10.6. По дизайну маки превосходят большинство PC вендоров на голову. Портирование софта на Mac имеет смысл если большинство клиентов софта в США, в США маки приближаются к 15%, в Европе около 5% и в России по оценкам 1-2%
Здравствуйте, CRT, Вы писали:
CRT>И в чем дезинформация? Человек хотел перенсти свое приложение на С++. Я сказал что придется еще изучать Objective-C и Cocoa чтобы хотя бы "интерфейсный слой" написать.
И неправильно сказал. Можно, например, писать на Qt и иметь один код для всех платформ сразу.
H>В противном случае порт будет болезненным. Дело не в том что Cocoa плох, напротив, это очень качественный фреймворк. Придется переосмысливать дизайн приложения и писать вещи связанные с GUI на Objective-C/Cocoa.
Не хочеться изучать Objective-C, а на С++ GUI писать можно ?
H>PS Купить МакБук или Мини — не проблема, на этом компе будут работать как WinXP/Vista/7 так и MacOSX 10.5/10.6. По дизайну маки превосходят большинство PC вендоров на голову. Портирование софта на Mac имеет смысл если большинство клиентов софта в США, в США маки приближаются к 15%, в Европе около 5% и в России по оценкам 1-2%
Здравствуйте, maks1180, Вы писали:
H>>В противном случае порт будет болезненным. Дело не в том что Cocoa плох, напротив, это очень качественный фреймворк. Придется переосмысливать дизайн приложения и писать вещи связанные с GUI на Objective-C/Cocoa. M>Не хочеться изучать Objective-C, а на С++ GUI писать можно ?
Нет.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, CRT, Вы писали:
CRT>>И в чем дезинформация? Человек хотел перенсти свое приложение на С++. Я сказал что придется еще изучать Objective-C и Cocoa чтобы хотя бы "интерфейсный слой" написать.
RO>И неправильно сказал. Можно, например, писать на Qt и иметь один код для всех платформ сразу.
можно, а еще на маке можно wxwidgets использовать
Но не всегда к сожалению такие приложения там выглядят как "родные"
Здравствуйте, Roman Odaisky, Вы писали:
CRT>>И в чем дезинформация? Человек хотел перенсти свое приложение на С++. Я сказал что придется еще изучать Objective-C и Cocoa чтобы хотя бы "интерфейсный слой" написать. RO>И неправильно сказал. Можно, например, писать на Qt и иметь один код для всех платформ сразу.
Для Маков это не работает. Точнее, получается очень некрасивые приложения.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Cyberax, Вы писали:
M>>>Не хочеться изучать Objective-C, а на С++ GUI писать можно ? C>>Нет.
Pzz>Можно, на Qt. А с objective-c Qt сама уж внутри себя разберется, если это так уж необходимо.
Что-то мне кажеться что в Маках через одно место, так как даже на С++ нельзя писать...
Qt тоже не хочу, так как у нас есть своя библиотека для Windows мы бы её портировали бы на MacOS если бы можно на С++ писать.
А так мне уже перехотелось связываться с Маками.
Я помню, что они всегда хотели отгородиться от других, например продавали компы на которых кроме Мака ничего не поставишь.
Пока чуть не обонкротились, тогда поняли что нужно компы продавать что-бы люди смогли туда другие ОС поставить.
Остаеться ждать пока до них дойдет, что программисты и маленькие компании не хотят изучать их велосипед (objective-c).
Надеюсь что это случиться быстрее, чем они обонкротятся...
Здравствуйте, maks1180, Вы писали:
M>Остаеться ждать пока до них дойдет, что программисты и маленькие компании не хотят изучать их велосипед (objective-c). M>Надеюсь что это случиться быстрее, чем они обонкротятся...
Они, по-моему, нащупали удачный способ ведения бизнеса и не очень переживают по поводу программистов и маленьких компаний, которые не хотят изучать их велосипед. Отгорождение от других, кстати, является существенной частью их бизнес-стратегии.
Здравствуйте, maks1180, Вы писали:
Pzz>>Можно, на Qt. А с objective-c Qt сама уж внутри себя разберется, если это так уж необходимо. M>Что-то мне кажеться что в Маках через одно место, так как даже на С++ нельзя писать...
Objective-C — это по-сути и есть API, просто немного более высокоуровневое, чем обычные С-шные API в других ОС.
H>>В противном случае порт будет болезненным. Дело не в том что Cocoa плох, напротив, это очень качественный фреймворк. Придется переосмысливать дизайн приложения и писать вещи связанные с GUI на Objective-C/Cocoa.
M>Не хочеться изучать Objective-C, а на С++ GUI писать можно ?
Objective-C на два порядка проще C++. После месяца работы с этим языком у меня было чувство что я знаю его намного лучше C++ на котором писал лет десять.
Пишите на Qt. Хотя знание Objective-C очень полезно — показывает как сложные вещи моожно сделать очень просто и Cocoa сам по себе очень интересен.
M>Что-то мне кажеться что в Маках через одно место, так как даже на С++ нельзя писать... M>Qt тоже не хочу, так как у нас есть своя библиотека для Windows мы бы её портировали бы на MacOS если бы можно на С++ писать. M>А так мне уже перехотелось связываться с Маками. M>Я помню, что они всегда хотели отгородиться от других, например продавали компы на которых кроме Мака ничего не поставишь.
Компании Apple совершенно все равно что о ней думает Вася Пупкин из Урюпинска.
M>Остаеться ждать пока до них дойдет, что программисты и маленькие компании не хотят изучать их велосипед (objective-c). M>Надеюсь что это случиться быстрее, чем они обонкротятся...
Для iPhone написано 150,000 приложений. Для того чтобы писать для iPhone надо купить мак (или хакинтош), заплатить 100 баксов и изучить Objective-C. Как мы видим, желающих выше крыши.
После Cocoa от Windows API будет невыносимо тошнить (чего не бывает с Qt, Qt и Cocoa имеют немало общего)
Здравствуйте, maks1180, Вы писали:
M>Что-то мне кажеться что в Маках через одно место,
Я неделю знакомлюсь с маком уже — и чо то мне начало казатся что там как раз все правильно.
M>так как даже на С++ нельзя писать...
Ну это явно вы сильно пошутили
M>Qt тоже не хочу, так как у нас есть своя библиотека для Windows мы бы её портировали бы на MacOS если бы можно на С++ писать.
Можно. QT\wxWidgets написаны на c++
Другое дело что кокоа идет в массы и совсем без обджектив — будет обойтись, наверное не то что бы нельзя, а просто глупо.
M>Пока чуть не обонкротились, тогда поняли что нужно компы продавать что-бы люди смогли туда другие ОС поставить.
вообще-то они перешли на интел из-за технологических причин вроде.
M>Остаеться ждать пока до них дойдет, что программисты и маленькие компании не хотят изучать их велосипед (objective-c).
Я вот тоже не хотел неделю назад, сейчас чаша весов склонилась в другую сторону
p.s. у меня сложилось впечетление что под маком шаровашикам особо делать будет нечего.
p.s.s. все вышенаписанное — рассматривать как рассуждение теоретика, знакомого с маком всего пару недель
Здравствуйте, maks1180, Вы писали:
M>хочу попробывать портировать софт для MacOS, покупать еще один ноут пока не хочеться. M>Можно ли как-то под WMWare или другим способом установить MacOS на обычном компьютере с процессором Intel ?
да, в в вмваре и на обычном компе, если не совсем дрова.
Здравствуйте, CRT, Вы писали:
C>>Objective-C — это по-сути и есть API CRT>objective-c — это язык програмирования CRT>API — это не язык программирования. Это вобще-то разные вещи
Не совсем Objective-C/C++ — это надстройка над С/C++, нужная для работы с платформенным API.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, CRT, Вы писали:
C>>>Objective-C — это по-сути и есть API CRT>>objective-c — это язык програмирования CRT>>API — это не язык программирования. Это вобще-то разные вещи C>Не совсем Objective-C/C++ — это надстройка над С/C++, нужная для работы с платформенным API.
Где вы такую траву берете?
русским же языком написанно:
Objective-C is a reflective, object-oriented programming language, which adds Smalltalk-style messaging to the C programming language. (с) wikipedia
К тому же на Objective-C можно писать не только для мака.
Здравствуйте, Begemot_, Вы писали:
C>>Не совсем Objective-C/C++ — это надстройка над С/C++, нужная для работы с платформенным API. B_>Где вы такую траву берете?
На практике.
B_>русским же языком написанно: B_>Objective-C is a reflective, object-oriented programming language, which adds Smalltalk-style messaging to the C programming language. (с) wikipedia
И что дальше-то? По факту, Objective-C на Маках работает слоем для работы с API. Т.е. API с системой строится не в виде С-шных функций (как в WinAPI или Линуксе), а в виде протоколов посылки сообщений Objective-C.
Здравствуйте, CRT, Вы писали:
C>>Т.е. API с системой строится не в виде С-шных функций (как в WinAPI или Линуксе), а в виде протоколов посылки сообщений Objective-C. CRT>Часть API на голом C.
Это понятно. POSIX тоже никто не собирался на Objective-C переписывать.
Здравствуйте, Cyberax, Вы писали:
C>И что дальше-то? По факту, Objective-C на Маках работает слоем для работы с API. Т.е. API с системой строится не в виде С-шных функций (как в WinAPI или Линуксе), а в виде протоколов посылки сообщений Objective-C.
И что это дает право называть Objective-C просто прослойкой — а не языком программирования?
а то так можно договорится что и С под виндой это не язык программирования, а просто прослойка для вызова апи...
Здравствуйте, Begemot_, Вы писали:
C>>И что дальше-то? По факту, Objective-C на Маках работает слоем для работы с API. Т.е. API с системой строится не в виде С-шных функций (как в WinAPI или Линуксе), а в виде протоколов посылки сообщений Objective-C. B_>И что это дает право называть Objective-C просто прослойкой — а не языком программирования?
Ну таки да
B_>а то так можно договорится что и С под виндой это не язык программирования, а просто прослойка для вызова апи...
А вот тут мимо. WinAPI может вызываться из других языков напрямую, а вот с Objective-C так не получается.
Здравствуйте, Cyberax, Вы писали:
B_>>И что это дает право называть Objective-C просто прослойкой — а не языком программирования? C>Ну таки да
то есть, ты хочешь сказать что на Objective-C нельзя написать программу работаюшую без cocoa?
и сам фрейморк cocoa написан на прослойке к самому себе же, а не на языке программирования Objective-C ?
B_>>а то так можно договорится что и С под виндой это не язык программирования, а просто прослойка для вызова апи... C>А вот тут мимо. WinAPI может вызываться из других языков напрямую, а вот с Objective-C так не получается.
смешались в кучу люди кони что не получается вызывать Objective-C (язык программирования) из другиъ языков? или использовать фреймворк cocoa из других языков не получается ???
итак:
Objective-C — язык программирования, основной предпочтительный для MAC OS в настоящее время
Cocoa — основной предпочтительный framework для MAC OS. Написан на Objective-C. может быть использован из разных языков благодаря существующим билдингам.
и опять же цитаты:
Cocoa — родная объектно-ориентированная среда разработки приложений для операционной системы Mac OS X производства компании Apple. Это один из пяти основных API, доступных в Mac OS X, — Cocoa, Carbon, Toolbox (для работы старых приложений Mac OS 9), POSIX и Java. Такие языки, как Perl, Python и Ruby не считаются основными, так как на них пока что пишется не так много серьёзных приложений.
Приложения, использующие Cocoa, обычно разрабатываются с помощью среды разработки Apple Xcode (в прошлом называвшегося Project Builder) и Interface Builder с использованием языка Objective-C. Однако, среда Cocoa так же доступна и при разработке на других языках, таких как Ruby, Python и Perl с помощью связующих библиотек (RubyCocoa, PyObjC и CamelBones соответственно). Также можно писать Cocoa-программы на Objective-C в обычном текстовом редакторе и вручную компилировать их с помощью GCC или make-сценариев для GNUstep.
Cocoa Frameworks
The Cocoa frameworks consist of libraries, APIs, and runtimes that form the development layer for all of Mac OS X. By developing with Cocoa, you will be creating applications the same way Mac OS X itself is created. Your application will automatically inherit the great behaviors and appearances of Mac OS X, with full access to the underlying power of the UNIX operating system. Using Cocoa with the Xcode IDE is simply the best way to create native Mac applications.
The Power of Objective-C
Much of Cocoa is implemented in Objective-C, an object-oriented language that is compiled to run at incredible speed, yet employes a truly dynamic runtime making it uniquely flexible. Because Objective-C is a superset of C, it is easy to mix C and even C++ into your Cocoa applications.
As your application runs, the Objective-C runtime instantiates objects based on executing logic—not just in ways defined during compilation. For example, a running Objective-C application can load an interface (a nib file created by Interface Builder), connect the Cocoa objects in the interface to your application code, then run the correct method once the UI button is pressed. No recompiling is necessary.
Objective-C’s dynamic runtime is similar to many modern scripting languages, making it easy to map Cocoa’s features to other languages using the Cocoa Bridge. With the Cocoa Bridge, developers can create first-class Mac OS X applications using AppleScript, Ruby, and Python.
Здравствуйте, Begemot_, Вы писали:
B_>>>И что это дает право называть Objective-C просто прослойкой — а не языком программирования? C>>Ну таки да B_>то есть, ты хочешь сказать что на Objective-C нельзя написать программу работаюшую без cocoa? B_>и сам фрейморк cocoa написан на прослойке к самому себе же, а не на языке программирования Objective-C ?
Я говорю, что программу для Cocoa нельзя написать без применения Objective-C.
C>>А вот тут мимо. WinAPI может вызываться из других языков напрямую, а вот с Objective-C так не получается. B_>смешались в кучу люди кони что не получается вызывать Objective-C (язык программирования) из другиъ языков?или использовать фреймворк cocoa из других языков не получается ???
Именно.
B_>итак: B_>Objective-C — язык программирования, основной предпочтительный для MAC OS в настоящее время B_>Cocoa — основной предпочтительный framework для MAC OS. Написан на Objective-C. может быть использован из разных языков благодаря существующим билдингам.
Байндингам. Но все байндинги всё равно работают через прослойку из Objective-C. Вроде только для SWT есть байндинг, эмулирующий протоколы напрямую.
Здравствуйте, icezone, Вы писали:
I>Здравствуйте, Begemot_, Вы писали:
B_>>p.s. у меня сложилось впечетление что под маком шаровашикам особо делать будет нечего.
I>Подозреваю, что во многих случаях это не так. Конкуренция меньше, фривар меньше, мне часто пишут и ищут аналоги моих программ для Мака.
Аналогично ... Регулярно спрашивают о портах программ для MAC OS X.
Советую воспользоваться Darwine, что реально просто отговорка.
С начала года начал таки портировать Win32 приложения через wxWidgets.
Крайне интересно как будут соотносится продажи под MAC и под Win32.
Здравствуйте, VaDroid, Вы писали:
VD>С начала года начал таки портировать Win32 приложения через wxWidgets.
о, а можно узнать какого типа приложения и как успехи — именно портирование через wxWidgets, как раз сейчас сильно интересует, может быть в приват.
Здравствуйте, Begemot_, Вы писали:
B_>Здравствуйте, VaDroid, Вы писали:
VD>>С начала года начал таки портировать Win32 приложения через wxWidgets. B_>о, а можно узнать какого типа приложения и как успехи — именно портирование через wxWidgets, как раз сейчас сильно интересует, может быть в приват.
Приложения из области Scientific-Publishing, Authoring/Prepress.
Точнее это целостная система в которой взаимодействуют несколько программ.
Откуда и берется необходимость в портировании всех сразу.
О портировании ...
К слову сказать, конец прошлого года (с осени) выбирал какую библиотеку использовать
для портирования (Unix/BSD/Linux тоже рассматривается как более удаленная перспектива).
Перепробовал много чего от больших до самых маленьких ...
Хотелось ведь и компактности...
В результате портированием через wxWidgets вполне доволен.
Есть конечно некоторые проблемы, ну я идеала и не ожидал.
А в общем, перегон из Win32 в wxWidgets вполне естественнен.
Ложится практически один в один.
Проблемы:
1) GDI — wxDC слишком ограничен, GraphicsContext не поддерживает
OTF шрифтов (ибо работает через GDI+ под Win32)
2) нет межпрограмного докинга окон как в GTK
(модно сейчас как в Chrome — каждый сайт отдельный процесс)
3) Иконки в меню: 2.8.10 — ужас, 2.9.0 — вообще исчезли.
4) Для использования embedded fonts пришлось отключить FONTENUM
А за ним HTML, RICHTEXT, GRID (хорошо что не нужны были).
Вот подозреваю что HTML все же понадобиться.
5) wxAUI — есть нюансы. Мне не нравиться что пользователь
может легко закинуть тулбар за пределы видимости
— юзабилити ...
Здравствуйте, VaDroid, Вы писали:
VD>В результате портированием через wxWidgets вполне доволен. VD>Есть конечно некоторые проблемы, ну я идеала и не ожидал. VD>А в общем, перегон из Win32 в wxWidgets вполне естественнен. VD>Ложится практически один в один.
Спасибо, а пишешь чисто под макос — или все таки будет кроссплатформенно, то есть один код для винды и мака?
VD>2) нет межпрограмного докинга окон как в GTK VD> (модно сейчас как в Chrome — каждый сайт отдельный процесс)
А где такое есть?
VD>3) Иконки в меню: 2.8.10 — ужас, 2.9.0 — вообще исчезли.
странно, я уже месяца 3 как перешел на trunk — иконки нормально (msw)
Здравствуйте, Begemot_, Вы писали:
B_>Здравствуйте, VaDroid, Вы писали:
VD>>А в общем, перегон из Win32 в wxWidgets вполне естественнен. VD>>Ложится практически один в один.
B_>Спасибо, а пишешь чисто под макос — или все таки будет кроссплатформенно, то есть один код для винды и мака?
Стараюсь кросплатформенно, ибо
(1) планируется так же под Unix/Linux — а еще раз портировать не хотелось бы
(2) с использованием wxAUI планируем несколько улучшить пользовательский интерфейс
(3) программы будут развиваться, а поддерживать несколько веток не хотелось бы.
Однако для GDI без системнозависимых кодов не обойтись.
VD>>2) нет межпрограмного докинга окон как в GTK VD>> (модно сейчас как в Chrome — каждый сайт отдельный процесс) B_>А где такое есть?
Как где, Chrome, Google Chrome.
Вроде бы некоторые другие браузеры (толи Safari, толи новый IE, не помню)
тоже переняли такой подход.
VD>>3) Иконки в меню: 2.8.10 — ужас, 2.9.0 — вообще исчезли. B_>странно, я уже месяца 3 как перешел на trunk — иконки нормально (msw)
Я использую 2.9 от 2009-09-08.
Это хорошо, что в trunk иконки работают нормально — т.е. пока можно с этим не париться.
Может ко времени и wxWidgets 3.0 выдут...
VD>>>2) нет межпрограмного докинга окон как в GTK VD>>> (модно сейчас как в Chrome — каждый сайт отдельный процесс) B_>>А где такое есть? VD>Как где, Chrome, Google Chrome.
насколько я помню их схемы, там есть главный процесс, который держит все закладки и коннекшены. и есть процессы-рендереры ХТМЛ. главный скачивает им контент, а они выдают ему, грубо говоря, картинку.
дочить окна разных процессов в одно окно — че-то я под виндой слабо в это верю.
Здравствуйте, ov, Вы писали:
VD>>>>2) нет межпрограмного докинга окон как в GTK VD>>>> (модно сейчас как в Chrome — каждый сайт отдельный процесс) B_>>>А где такое есть? VD>>Как где, Chrome, Google Chrome.
ov>насколько я помню их схемы, там есть главный процесс, который держит все закладки и коннекшены. и есть процессы-рендереры ХТМЛ. главный скачивает им контент, а они выдают ему, грубо говоря, картинку. ov>дочить окна разных процессов в одно окно — че-то я под виндой слабо в это верю.
<<дочить>> окна разных процессов в окна других процессов можно
под виндой без проблем. Работает под всеми версиями Win32
(возможно кроме 3.1 :=) Win95, ... Win7 — проверено.
B_>>А где такое есть? VD>Как где, Chrome, Google Chrome.
Я имею ввиду, где из фреймворков..
B_>>странно, я уже месяца 3 как перешел на trunk — иконки нормально (msw) VD>Я использую 2.9 от 2009-09-08. VD>Это хорошо, что в trunk иконки работают нормально — т.е. пока можно с этим не париться. VD>Может ко времени и wxWidgets 3.0 выдут...
Да я думаю в плане иконок не особо разница должна быть, может что-то не то делаешь?
А чо 2.9,trunk уже сильно вперед ушел..., особенно маковская версия. Правда там 23 января сломали иконки в меню немного (совпадение так что я сижу на версии 2х месячно давности, но кусаю локти что не могу свежее взять, из-за иконок.
Здравствуйте, Begemot_, Вы писали:
B_>Здравствуйте, VaDroid, Вы писали:
B_>>>А где такое есть? VD>>Как где, Chrome, Google Chrome. B_>Я имею ввиду, где из фреймворков..
B_>>>странно, я уже месяца 3 как перешел на trunk — иконки нормально (msw) VD>>Я использую 2.9 от 2009-09-08. VD>>Это хорошо, что в trunk иконки работают нормально — т.е. пока можно с этим не париться. VD>>Может ко времени и wxWidgets 3.0 выдут... B_> Да я думаю в плане иконок не особо разница должна быть, может что-то не то делаешь?
Не знаю, но в 2.8.10 работало, хоть и некрасиво — нативно красивее.
А после пересборки под 2.9.0 иконки просто исчезли.
B_> А чо 2.9,trunk уже сильно вперед ушел...,
Вполне может быть что смахнули случайно и восстановили в однм из фиксов.
> особенно маковская версия.
Я не использовал 2.9,trunk и не знаю как далеко он ушел.
Но после перекомпиляции с 2.8.10 под 2.9.0 некоторые элементы
управления (например Color Picker) стали выглядеть более вразумительно.
Все под carbon. К стати, может следует использовать вариант Cocoa ?
> Правда там 23 января сломали иконки в меню немного (совпадение > так что я сижу на версии 2х месячно давности, но кусаю локти что > не могу свежее взять, из-за иконок.
Ага, значит чего то они там с иконками в меню все таки химичат.
Та чего же удивляться ... Идет процесс.
Посмотрим, может доделают.
Здравствуйте, ov, Вы писали:
VD>><<дочить>> окна разных процессов в окна других процессов можно VD>>под виндой без проблем. Работает под всеми версиями Win32
ov>а где на это можно посмотреть или почитать об этом? хром не в счет, там не так сделано.
Да любой Win API reference manual.
Cм. CreateProcess и WM_PARENTNOTIFY
Здравствуйте, VaDroid, Вы писали:
VD>Здравствуйте, ov, Вы писали:
VD>>><<дочить>> окна разных процессов в окна других процессов можно VD>>>под виндой без проблем. Работает под всеми версиями Win32
ov>>а где на это можно посмотреть или почитать об этом? хром не в счет, там не так сделано.
VD>Да любой Win API reference manual. VD>Cм. CreateProcess и WM_PARENTNOTIFY
Ошибся
Cм. CreateWindow(Ex) и WM_PARENTNOTIFY
Впрочем, CreateProcess тоже будет нужен.
VD>Cм. CreateWindow(Ex) и WM_PARENTNOTIFY VD>Впрочем, CreateProcess тоже будет нужен.
попробовал — реально можно создать дочернее окно в другом процессе. потом можно переопределить оконную процедуру и ловить все сообщения.
не знал, удивлен, спасибо. думал с включенным UAC пойду в лес, а не пошел...
впрочем, "хромовский" подход мне все равно больше нравится. мухи — отдельно, котлеты отдельно. плюс там еще процессы, которые рендерят страницы, лишены вообще всех возможных прав. с диском общаться не могут, с сетью тоже — все через главный процесс.
Здравствуйте, VaDroid, Вы писали:
VD>Все под carbon. К стати, может следует использовать вариант Cocoa ?
Я под мак компилил кокоа, но это надо явно указывать при сборке либы. Кокоа еще сыровата и сейчас активно разивается, так что если я правильно понял сейчас используется некий микс из карбона и кокоа, и постепенно первое замещают вторым.
Здравствуйте, maks1180, Вы писали:
>Удаленный доступ за секунды >Remote Access within seconds
Судя по подписи, хакинтош Вм не подойдет.
В целом по всему, что в теме:
На C++ писать под Мак вполне можно. Carbon никто не отменял, и Qt уже год, как имеет родной look and feel. Кроме того, некоторые вещи можно написать исключительно на C, и это отнюдь не драйвера, а довольно банальная работа с изображениями.
__>В целом по всему, что в теме: __>На C++ писать под Мак вполне можно. Carbon никто не отменял, и Qt уже год, как имеет родной look and feel. Кроме того, некоторые вещи можно написать исключительно на C, и это отнюдь не драйвера, а довольно банальная работа с изображениями.
Carbon-64 пошел под нож. так что как минимум для 64 бит — только Cocoa.
Кстати, qt при сборке можно указхать фреймворк — Carbon или Cocoa.
