HIG

Що е то?
HIG е често използвана абревиатура и означава Human Interface Guidelines, на български - насоки за създаване на потребителски интерфейс. В десктоп работните среди това са насоките които се очаква да следват програмистите и дизайнерите на приложенията за да ги направят по-лесни, удобни и приятни за употреба. Не на последно място и по-интуитивни.

Аз не претендирам да разбирам много от тази материя, но нищо не пречи да си кажа мнението, след като съм се запознал с няколко документа по въпроса. На първо място започнах с помощната документация която може да бъде намерена на страницата за програмисти на Apple. Документът не е от най-кратките, но според мен си струва да се прочете. Детайлите са много (включително препоръчваните отстояния в пиксели между елементите и така нататък), но странно защо имаше голям смисъл, поне за мен. Сигурно за никой не е тайна ,че съм голям фен на Aqua интерфейса. Опитвал съм се да пригодя някои от характерните за него елементи към GTK с по-глолям или по-малък успех (например Focus ring). Анимацията също смятам, че използвана разумно добавя много за улесняване на взаимодействието с потребителя. Едно от нещата които все още не знам как да осъществя е обезцветяването на контролните елементи на неактивните прозорци, добавянето на бутон за оразмеряване на прозореца (както всички вече знаете такъв бутон се поддържа от (почти?) всеки мениджър на прозорци, но някак си не-интуитивно се работи с тях, дори ако сте имало опит с Уиндоус се сещате че там така наречения Resize Grip присъства. Разбира се window frame (рамка на прозореца) позволява промяна на размера, но какво правим ако нямаме рамка на прозореца (тоест използваме мениджър на прозорци който позволява рамката да бъде с големина 0) ? Ами... остава ни да използваме бутона (ами ако сме решили че не искаме да има такъв?) или да се надяваме разработчика да е добавил а) StatusBar и б) resize grip на него.
Следващото което прави неприятно впечатление е липсата на гъвкавост по отношение на менютата, докато тази функционалност присъства в KDE то тя е доста недодялана в ГТК все още.
Актуализация: AqD написа поправка към GTK 2.10 която в последствие порт-на към GTK 2.8 и аз имах удоволствието да я изпробвам лично. Първоначално кръпката беше доста недодялана (например менюто изчезваше ако се активира контекстно меню или се влачи прозореца) също така не можеше да се интегрират менютата с панела, но днес посетих отново страницата на проекта и О ЧУДО, имаме си вече аплет за панела, който помества менютата, да им е честито на Mac OSX любителите! За съжаление кръпката за 2.8 не се поддържа и няма да се обновява.

Странната имплементация на някои уиджети поставя пред сериозно изпитание създаването на декорация за елементите следващи подобни на Aqua HIG. Едно от нещата е, разбира се е, че уиджетите са различни от тези в Cocoa . Например типовете бутони (най-ясната разлика), типовете визуални разграничители и други. Голям напредък за дизайнерите на теми беше въвеждането на възможността да се променят отстъпите и размерите на някои уиджети чрез темите в GTK2. Един типичен пример за често задаван в темите размер на уиджет е scrollbar и slider. За съжаление задълбоченото познаване на GTK е наложително за да се използват тези възможности.
Но дори те не могат да се справят с някои ограничения на имплементацията по отношение на "theming". Ще изброя някои от тях с цел илюстрация:

• GtkToolButton - това са бутоните използвани в горната част на прозорците, например контролите на Nautilus или Gedit. За съжаление, макар да са много различни като предназначение и тип и логиката е поне да могат да се изчертават по начин различен от обикновените бутони, тези бутони напълно еднакво се изчертават както обикновения GtkButton. Всичките ми опити до сега да променя това са безрезултатни.


• Променените от някой програмист уиджети, извлечени от основния тип, но неподдаващи се на theming. Ужасно дразни, а на всичкото отгоре нямам идея как да се справя с това за сега, примери за това са widgets в: Grisbi, Evolution, Epiphany LocationBar и други


• Липсата на стабилна документация за най-често използвания engine - pixmaps. Всичко на всичко което се знае за този модул е това което успее дизайнера на темата да схване от чуждите работи и коментари и евентуално ако чете кода и доразбере нещо.


• Липсата на приложение за тестване на темите, съдържащо всички уиджети (включително с имената им), което да може да променя използвания стил без да се сменя системния такъв - това много би ускорило тестването на стиловете поне за стандартните контроли (уиджети)


• Липса на лесен и надежден начин за получаване на името и path-а на уиджет директно от работеща програма, например искате да направите тема за определен уиджет в определено приложение, но не знаете какъв е той, ако имаше начин просто да кликнете на него и в stdout да ви се изпише името щеше да е къде къде по-лесно


• Няма документирана възможност за стилизиране на конкретни уиджети в конкретни приложения, макар че очевидно това е възможно(как?) - виждали сме го в няколко теми вече и наистина работи (и как все пак?)

Не мога да претендирам да познавам добре GTK, нито начините за стилизирането му, но от набраната до момента информация (няколко дни стабилно ровене и четене както на помощната документация (sgml през DevHelp) така и на изходния код) ми показаха че с някои неща няма да мога да се справя, без да задълбая наистина сериозно в interenals. А дори и тогава се съмнявам да успея. Бих се радвал ако някой има по-голям опит и разбиране по въпроса помогне, но за сега не се е намерил такъв, хем знаещ, хем желаещ да помогне.
Ето някои от нещата, които ме спъват за сега:

• Изчертаване на фокуса: безумно много ме дразни това че само текстовите контроли (GtkEntry, GtkText, GtkEditable и прочее) се поддават на "фокусиране". Според мен трябва това да се отнася в пълна степен и за листингите, защото може да се скролира с клавиатурата през тях и да се активират Items там с натискането на Enter, което ги прави по логиката на HIG пълноправни кандидати за приемане на Input events следователно - фокусирането им.


• Не знам как да изчертавам контроли различно според къде са използвани(в каква йерархия), например: GtkCList има в себе си GtkLabel, който, за да променя, използвам следния код
  style "stylename" {
  font_name = "Font Name pointsize"
  }
  widget_class "*.GtkCList*.*GtkLabel*" style = "stylename"
  и това работи, дори да имам другаде зададен различен стил за GtkLabel. Но например не работи за бутоните в GtkToolButton, може би просто не знам как правилно да се обръщам към тях, вече и аз не знам какво става.

Бавно но славно напредвам с моят стил, който съм намислил освен всичко друго да бъде и едно своеобразно помагало за желаещите да изучават начините на стилизиране на обектите от GTK. Вече съм доста наясно че никога няма да мога да постигна Aqua изгледа, да не говорим за поведението (най-малкото анимациите) но мисля че доста красиви и практични неща могат да се получат. За мен разбира се най-важното в това начинание остава доближаване до HIG, а именно, по-добре и по-бързо да може да се ориентира потребителя в това какво се случва с програмата и така нататък, като основната цел в момента ми е пълно и цялостно проследяване на Input focus и Default widget (бил той бутон или друго - както в случаите с диалозите например, Input фокуса може да бъде GtkEntry поле, но default контролата да е Ok или Cancel бутона.)
Отправям призив към всеки който има познания в областта и сведения и иска да помогне да ми пише с информация за контакт. Всяка помощ е добре дошла!
Мисля също така, че следващият път когато Гном се сдобива с нов стил "по подразбиране" той трябва да е много по-добре обмислен (вкл. възможностите които предлага, като проследяване на фокуса, действията по подразбиране и тн, неща които липсват в настоящата реализация (Clearlooks*).

*Clearlooks беше голяма стъпка напред, след годините на грозна тема по подразбиране, но това да се проследява фокуса само в GtkEntry полетата си беше едно недомислие. Също така се оказа че да се изчертават уиджетите само с Cairo не е толкова лесно колкото си мислеха всички. А и този модул предлага твърде малко методи за настройка на външния вид на приложенията.