Компьютерный форум
Правила
Вернуться   Компьютерный форум > Форум программистов > Программирование под *nix > Общие вопросы программирования
Перезагрузить страницу Принципы оконного интерфейса
Ответ
 
Опции темы Опции просмотра
  (#16 (permalink)) Старый
Кошмар Кошмар вне форума
Member
 
Сообщений: 2,694
Сказал(а) спасибо: 0
Поблагодарили 1 раз в 1 сообщении
Регистрация: 23.04.2005
По умолчанию 11.11.2007, 16:56

Цитата:
Однако, запускаются приложения в "родной" среде несколько быстрее.
Потому что в родной среде библиотеки уже подгруженны?


импортирован с progz.ru
Ответить с цитированием
  (#17 (permalink)) Старый
Arachnelis Arachnelis вне форума
Member
 
Сообщений: 1,324
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 02.07.2007
Thumbs up 11.11.2007, 20:20

Цитата:
KDE'шный проводник из под GNOME запускать тоже никто не мешает, как и из консоли
Эта фраза повергла меня в шок, а оттуда - в ступор.
По этой фразе я так понял, что загрузив, комп без GUI, с коммандной строки, можно запустить приложение, написанное с граф. интерфейсом, но оно будет работать без графики, с теми же консольными командами - так что ли??? Или она попытается активизировать-таки библиотеки и запустится со своим GUI на фоне черного экрана???
Ответить с цитированием
  (#18 (permalink)) Старый
Alexey Dejneka Alexey Dejneka вне форума
Member
 
Сообщений: 451
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 23.11.2004
По умолчанию 11.11.2007, 22:11

Цитата:
По этой фразе я так понял, что загрузив, комп без GUI, с коммандной строки, можно запустить приложение, написанное с граф. интерфейсом, но оно будет работать без графики, с теми же консольными командами - так что ли???
В Unix программы не делятся на графические/текстовые/FTP-сервера/telnet-клиенты и т.п. Все они - просто программы.
Графическое приложение просто в какой-то момент своей жизни устанавливает связь через сеть с X-сервером и посылает ему команды на рисование чего-нибудь. При этом, ничто не мешает приложению выдавать информацию на какие-либо консоли или обращаться по сети к любым другим серверам.

Например, текстовый редактор Emacs при запуске пытается найти X-сервер; если находит - работает через него "в графическом режиме"; если не находит - работает в текстовом терминале, с которого его запустили. Независимо от этого, в любой момент времени ему можно дать команду вывестись еще на любой X-сервер или на любой терминал.

Наконец, те X-сервера, с которыми я сталкивался в Linux, - это просто программы, запускаемые из командной строки так же, как и любые другие. Есть программы - display manager-ы, которые:
- запускаются с консоли в "текстовом" режиме;
- запускают X-сервер;
- выводят на него графическое окошко регистрации пользователя.
Ответить с цитированием
  (#19 (permalink)) Старый
Arachnelis Arachnelis вне форума
Member
 
Сообщений: 1,324
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 02.07.2007
Post 11.11.2007, 22:42

Блин, *nix рулит!!!

Жив буду - выучу, только начну с QT / wxWidjets (правда, я так и не понял, что лучше для коммерческого и бесплатного использования и что лучше с разными компиляторами сочетается )!

Всегда считал, что именно так и должна быть устроена ОС с GUI.
Ответить с цитированием
  (#20 (permalink)) Старый
Alexey Dejneka Alexey Dejneka вне форума
Member
 
Сообщений: 451
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 23.11.2004
По умолчанию 11.11.2007, 22:53

Что Вы все - Unix, Unix... X11 и под MS Windows работает. За клиентскую часть не поручусь - а вот XMing X server пользуюсь регулярно - нужно с несколькими графическими Linux-программами работать из-под Windows, а переписывать их лень.
Ответить с цитированием
Ads.
  (#21 (permalink)) Старый
Matematic Matematic вне форума
Member
 
Аватар для Matematic
 
Сообщений: 388
Сказал(а) спасибо: 31
Поблагодарили 8 раз(а) в 8 сообщениях
Регистрация: 15.01.2007
По умолчанию 12.11.2007, 03:33

Цитата:
В Windows не программировал, что такое "каркасный принцип" не знаю.
Alexey Dejneka!
Каркасными приложениями в Windows обычно называют тот тип оконных программ, которые в основном и составляют подавляющее большинство приложений Windows. Другой тип программ под Windows - консольные приложения, но они, насколько я знаю, не могут содержать графики. О системных программах, драйверах и пр. я не говорю, поскольку это другой тип программ и к прикладным программам их обычно не относят. Оконные приложения Windows работают по тому принципу, который я изложил в этом посте
.

Вот исходник из книжки Юрова по ассемблеру
Код:
#include <windows.h>
LRESULT CALLBACK WindowProc(HWND ,UINT ,WPARAM ,LPARAM);
char szClassWindow[] = "КаркасноеПриложение";    /*Имя класса окна*/
int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hPrevInst, LPSTR lpszCmdLine, int nCmdShow)
{
    HWND hWnd;
    MSG lpMsg;
    WNDCLASSEX wcl;
/* Определение класса окна */
wcl.cbSize = sizeof (wcl);    //длина структуры WNDCLASSEXA
wcl.style = CS_HREDRAW|CS_VREDRAW;    //CS (Class Style) - стиль класса окна
wcl.lpfnWndProc = WindowProc;    //адрес функции окна
wcl.cbClsExtra  =0;    //для внутреннего использования Windows
wcl.cbWndExtra  = 0;     //для внутреннего использования Windows
wcl.hInstance = hInst;    //дескриптор данного приложения
wcl.hIcon = LoadIconA(NULL,IDI_APPLICATION);    //стандартная иконка
wcl.hCursor = LoadCursorA(NULL,IDC_ARROW);    //стандартный курсор
wcl.hbrBackground =(HBRUSH)GetStockObject (WHITE_BRUSH); // определить заполнение окна белым цветом
wcl.lpszMenuName = NULL;    //без меню
wcl.lpszClassName = szClassWindow;    //имя класса окна
wcl.hIconSm=NULL;    //дескриптор маленькой иконки, связываемой с классом окна

//зарегистрировать класс окна
if (!RegisterClassEx (&wcl))
return 0;
//создать окно и присвоить дескриптор окна переменной hWnd
hWnd=CreateWindowEx(
    0,        //расширенный стиль окна
    szClassWindow,    //имя класса окна
     "Каркас программы для Win32 на С++",    //заголовок окна
    WS_OVERLAPPEDWINDOW,    //стиль окна
    CW_USEDEFAULT,    //X-координата верх. левого угла окна
    CW_USEDEFAULT,    //Y-координата верх. левого угла окна
    CW_USEDEFAULT,    //ширина окна
    CW_USEDEFAULT,    //высота окна
    NULL,    //дескриптор родительского окна
    NULL,    //дескриптор меню окна
    hInst,    //идент. приложения создавшего окно
    NULL);    //указатель на область данных приложения
//показать окно и перерисовать содержимое
ShowWindow (hWnd, nCmdShow);
UpdateWindow (hWnd);
/* запустить цикл обработки сообщений */
while (GetMessage(&lpMsg,NULL,0,0))
{
    TranslateMessage(&lpMsg);    //разрешить использование клавиатуры
    DispatchMessage(&lpMsg);    //вернуть управление Windows
}
    return lpMsg.wParam;
}    //конец WinMain
LRESULT CALLBACK WindowProc (HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
//Функция WndProc вызывается операционной системой Windows 95
//и получает в качестве параметров сообщения из очереди 
//сообщений данного приложения
{
    switch(message)
    {
    case WM_DESTROY: /* завершение программы */
    PostQuitMessage (0);
    break;
    default:
    //Сюда попадают все сообщения, не обрабатываемые в данной оконной функции.
    //Далее эти сообщения направляются обратно Windows на обработку по умолчанию
    return DefWindowProc (hWnd, message, wParam, lParam);
}
return 0;
}
Эта программа ничего не делает, но содержит, как я понял, минимум для создания каркасного оконного приложения.

Я сам никогда не программировал под Windows и приложения этого типа никогда не создавал, более того не являюсь профессиональным программистом, поэтому мог что-то напутать. Но вроде бы в книжках пишут так. Пусть более знающие ребята меня поправят, если я что-то описал неправильно.
Никакой альтернативы этому способу для создания графических программ Windows, насколько мне известно, не предлагает. Более того, такая структура программы жестко предопределена самой ОС. От себя добавлю, что эта структура мне очень не нравится.

Вот и хотел узнать, графические приложения Linux под KDE и GNOME пишутся и работают по тому же принципу, что и упомянутое мной приложение Windows, с той же оконной функцией, с той же инициализирующей функцией, аналогом WinMain, с вызовом всех функций-алгоритмов из оконной функции, с алгоритмом, встроенным по сути дела в интерфейс? Или же разработчики обеих оболочек придумали что-то другое, что-то более классическое?
Ответить с цитированием
  (#22 (permalink)) Старый
Narwal Narwal вне форума
Member
 
Сообщений: 1,039
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 07.10.2003
По умолчанию 12.11.2007, 04:09

Цитата:
Никакой альтернативы этому способу для создания графических программ Windows, насколько мне известно, не предлагает.
Вполне даже предлагает. Вызовывсех функций, особенно, которые чего-то там будут считать довольно часто практически никак не связаны с GUI. См. Visual Studio хотя бы.
Ответить с цитированием
  (#23 (permalink)) Старый
Arachnelis Arachnelis вне форума
Member
 
Сообщений: 1,324
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 02.07.2007
Lightbulb 12.11.2007, 04:46

Цитата:
Вполне даже предлагает. Вызовывсех функций, особенно, которые чего-то там будут считать довольно часто практически никак не связаны с GUI. См. Visual Studio хотя бы.
Это они уже потом, "в недрах" программы не связаны, а в целом любая часть программы заключена в цикл обработки сообщений. Я не знаю, можно ли создать GUI-окно в приложении, по умолчанию созданному как консоль. Но даже если некоторый код "внутри себя" создает окно, дальнейшие действия либо все равно "вложены" в это окно, либо все смотрится IMHO довольно криво, т.к. фактически вложенная сущность взывает к охватывающей.

Да, есть функции, вызываемые "сами по себе", даже многие из тех, что используются и в GUI. Но я думаю, это везде так - ОС предоставляет свои средства в свободное пользование. А по сути программа Windows находится внутри интерфейса, без вариантов. И на мой взгляд, виновата в этом ТОЛЬКО пара "цикл сообщений" - "оконная процедура". Их могли бы и по-лучше сделать, а к остальному вроде прензий особых нет, местами даже восторг вызывает (NLS, например).
Ответить с цитированием
  (#24 (permalink)) Старый
Alexey Dejneka Alexey Dejneka вне форума
Member
 
Сообщений: 451
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 23.11.2004
По умолчанию 12.11.2007, 08:31

Цитата:
Вот и хотел узнать, графические приложения Linux под KDE и GNOME пишутся и работают по тому же принципу, что и упомянутое мной приложение Windows, с той же оконной функцией, с той же инициализирующей функцией, аналогом WinMain, с вызовом всех функций-алгоритмов из оконной функции, с алгоритмом, встроенным по сути дела в интерфейс?
По крупному - да, алгоритмы встраиваются в интерфейс (хотя можно запустить отдельные нити/процессы и организовывать в них работу, как хочется). GNOME и KDE ориентированы на событийный подход. По мелочам - нет, такие глобальные механизмы, как цикл приёма и разбора сообщений, встроены в систему, программист пишет мелкие обработчики конкретных событий.

Пример несложного Qt-приложения: http://doc.trolltech.com/4.3/tutorial-t12.html
Ответить с цитированием
Ads
  (#25 (permalink)) Старый
Arachnelis Arachnelis вне форума
Member
 
Сообщений: 1,324
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 02.07.2007
Thumbs up 15.11.2007, 13:44

Еще вопрос.

В Windows едва ли не во главе угла стоит набор функций для работы с растровыми изображениями - ::BitBlt(), ::MaskBlt(), ::TransparentBlt(), ::StretchBlt()...
Они важны как в самой работе GUI, так и при создании разного рода приложений, работающих с графикой.
Интересует, как с этим обстоят дела в Linux.

1. Важны ли при формировании интерфейса на простейшем уровне (X-Window System) растровые функции?
2. При создании приложений, работающих с графикой используются те же функции, что и в GUI, или отдельный набор?
3. Какие графические форматы "зашиты" в основу Linux? (например, в Windows это BMP (раскладывается на device-dependent bitmap - DDB - и device-independent bitmap - DIB), WMF/EMF, вроде еще что-то есть)
4. IMHO важнейшая ::BitBlt(), копирующая растр без масштабирования, но с учетом широкого спектра растровых операций, имеет следующую сигнатуру:
Код:
BOOL BitBlt(
    HDC hdcDest, // handle to destination device context 
    int nXDest,  // x-coordinate of destination rectangle's upper-left corner
    int nYDest,  // y-coordinate of destination rectangle's upper-left corner
    int nWidth,  // width of destination rectangle 
    int nHeight, // height of destination rectangle 
    HDC hdcSrc,  // handle to source device context 
    int nXSrc,   // x-coordinate of source rectangle's upper-left corner  
    int nYSrc,   // y-coordinate of source rectangle's upper-left corner
    DWORD dwRop  // raster operation code 
);
а коды растровых операций (ROP) формируются булевой арифметикой и кодируются битами в польской нотации.
Если можно, хотелось бы увидеть сигнатуру аналога функции копирования растра и системы ROP в Linux.
Очень нужно.

Аналогичные вопросы касательно QT/wxWidjets:
5. Какое положение в них занимает работа с растром для повседневной работы?
6. Имеются ли классы/функции для высокоскоростной работы с растром (т.е. почти напрямую передающие значения в функции ОС с минимальными лишними операциями)?
Ответить с цитированием
  (#26 (permalink)) Старый
Alexey Dejneka Alexey Dejneka вне форума
Member
 
Сообщений: 451
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 23.11.2004
По умолчанию 15.11.2007, 23:10

Цитата:
3. Какие графические форматы "зашиты" в основу Linux?
В основу Linux - никакие. В X11 - xwd и xbm. Для остальных используйте библиотеки.

Цитата:
4. IMHO важнейшая ::BitBlt(), копирующая растр без масштабирования, но с учетом широкого спектра растровых операций, имеет следующую сигнатуру:
...
Если можно, хотелось бы увидеть сигнатуру аналога функции копирования растра и системы ROP в Linux.
http://tronche.com/gui/x/xlib/graphics/XCopyArea.html для передачи внутри X-сервера (между двумя окнами/pixmaps в памяти сервера), http://tronche.com/gui/x/xlib/graphics/XPutImage.html для передачи от клиента к серверу. ROP задается в графическом контексте.

Цитата:
6. Имеются ли классы/функции для высокоскоростной работы с растром (т.е. почти напрямую передающие значения в функции ОС с минимальными лишними операциями)?
XShm, XVideo.
Ответить с цитированием
  (#27 (permalink)) Старый
Arachnelis Arachnelis вне форума
Member
 
Сообщений: 1,324
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 02.07.2007
Thumbs up 25.11.2007, 12:21

Еще интересует вопрос терминологии.

Всегда казалось, что термин "Window" - "Окно" - это придумка мелкомягких. Мозг клинит при попытке понять, почему интерактивный виртуальный экран приложения (пусть даже в 1981 году никто и не фантазировал о том, что он может стать трехмерным), снабженный различными областями для ввода и вывода различной информации, называется тем же словом, что и световая прорезь в стене (насколько я понимаю, "окно" происходит от "око").

Что характерно - терминология существует не только на уровне документации, но и на уровне самого WinAPI:
CreateWindow(), HWND, struct WNDCLASS...


Как дела у соседей?

А кто-нибудь достоверно знает, <strike>какому</strike> кому принадлежит авторство этой терминологии и в какие годы?
Ответить с цитированием
  (#28 (permalink)) Старый
Alexey Dejneka Alexey Dejneka вне форума
Member
 
Сообщений: 451
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 23.11.2004
По умолчанию 25.11.2007, 12:45

Я думал, что Window придумали в Xerox, но оказалось, что это было раньше: http://en.wikipedia.org/wiki/Window_%28computing%29.
Ответить с цитированием
  (#29 (permalink)) Старый
Dian Dian вне форума
Member
 
Сообщений: 5,243
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 17.09.2004
По умолчанию 25.11.2007, 15:10

К дискуссии о встраивании алгоритмов в интерфейс (а) и наоборот(б):

Итого: оконная система windows предалгает только вариант (а) - "алгоритмы внутри интерфейса", либо вынос алгоритмов в поток. Оконная система никсов, хотя и допускает встраивание (б) на уровне Xlib, но на более высоком уровне опорных библиотек KDE/GNOME это не используется - эти библиотеки сводят работу к тому же принципу, что и в windows. И это не случайно. Я подозреваю, что в настоящее время по меньшей мере 90% существующего ПО как раз и относятся к числу "хрени", отвечающей на события/запросы. Я также подозреваю, что по меньшей мере 99% ПО, которое будет создано в ближайшие 3 года будет работать по тому же принципу... А вот серьёзность приложений с таким подходом - большой вопрос: посмотрите на ту же Visual студию - она работает как раз так, и я бы не назвал её несерьёзной... а построеные на этом принципе клиент-серверные приложения - ладно ещё apache, но что можно написать "более серьезного и содержательного" чем, скажем, Oracle?
Ответить с цитированием
  (#30 (permalink)) Старый
Dian Dian вне форума
Member
 
Сообщений: 5,243
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 17.09.2004
По умолчанию 25.11.2007, 15:23

и ещё
Цитата:
Действительно, там, где первичен алгоритм, идея, сама программа, он ее дробит на части, заставляет занять ее неподобающее место в коде, вынуждает автора программы концентрироваться на внешней стороне, на картинках, украшательствах, ибо они теперь - основной алгоритм, вместо того, чтобы углубиться в создание основного алгоритма
Это происки маздая! Кто навязал вам необходимость работать с окнами?
На самом деле уже очень давно существует принцип разделения логики и интерфейса, т.е. связи между ними должны быть минимальны - тогда уж никак интерфейс на алгоритм влиять не будет. В никсах, кстати, этот принцип, похоже, возвели в идеал - об этом говорит наличие back-end'ов и front-end'ов - т.е. если вы можете написать алгоритм - пишите его в консольном варианте. Позже к нему можно будет сделать front-end - т.е. графическая оболочка будет обращаться прямо к консольному приложению.

Цитата:
Например, надо сделать плагиновую структуру для кроссплатформенной программы. Плагин должен иметь оконный интерфейс. И что, куда его пихать?
Пихать надо не интерфейс, а того, кто придумал такое требование... Куда - не скажу
Во-первых, окна в плагине - далеко не самая удачная идея. Во-вторых, требовать ещё и кросплатформенных окон - это уже просто жесть.
Ответить с цитированием
Ответ

Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Trackbacks are Вкл.
Pingbacks are Вкл.
Refbacks are Выкл.


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Некоторые принципы по написанию программ, для новичков dect Общие вопросы создания ПО 15 24.09.2011 19:18
Общие принципы организации синтаксического разбора в С++ 45182 Вопросы начинающих программистов 2 09.01.2011 18:41
Программа демонстрирующая принципы ООП (полиморфизм, инкапсуляцию, наследование) TidalAeon Вопросы начинающих программистов 0 11.12.2010 16:32
Принципы управления DVD и CD приводами tumanovalex Железо. Написание драйверов 0 29.08.2008 00:21
Принципы решения написания программы Frullani Lisp 2 27.09.2007 19:23
Принципы форматирования файлов shatush Общетематический 3 29.06.2007 23:16
Создание оконного приложения для Windows с 98 на VS2005 Antsu Visual C++ 5 17.01.2007 10:34
Объясните общие принципы работы CAsyncSocket Palmman Сетевое программирование 2 02.10.2006 20:28
Принципы создания средствами VC++ 6.0 интерфейса типа "проводник" Postum Visual C++ 8 26.01.2005 18:10
Принципы написания трояна Anonymous Delphi 30 19.03.2004 16:37
Принципы DoS-атак как их создавать Felix Delphi 2 11.01.2004 06:27
Принципы работы менеджера виртуальных экранов lv Visual C++ 0 01.11.2003 05:24



Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Нardforum.ru - компьютерный форум и программирование, форум программистов