Здравствуйте, 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 пойду в лес, а не пошел...
впрочем, "хромовский" подход мне все равно больше нравится. мухи — отдельно, котлеты отдельно. плюс там еще процессы, которые рендерят страницы, лишены вообще всех возможных прав. с диском общаться не могут, с сетью тоже — все через главный процесс.
так что я сижу на версии 2х месячно давности, но кусаю локти что не могу свежее взять, из-за иконок.
