Ничего не делают свойства Borderstyle и Bordericons в Linux

[alexmai]

Господа , обьясните новичку в Lazarus для чего оставлять свойства формы если они не работают в Линуксе.
Что теперь методом научного тыка искать что работает, что нет ?
То что умеет винда, вообщем-то и Дельфи сделает. Мне кажется надо добиваться 100% выполнения всех обозначенных свойств и методо НЕ в WINDOWS.
Два свойства BorderStyle и BorderIcons работают в Линуксе только в двух режимах
1. BorderStyle:=bsNone тогда автоматом Bordericons-[] ,нет заголовка формы вообще и то очень коряво правая граница отсутствующего заголовка убирается.
1. BorderStyle равно любому значению из перечисления, тогда тупо рисуется заголовок со всеми элементами( biSystemMenu,biMinimize,biMaximize]
В винде естественно все нормально.
Как обойти эти грабли, мне надо чтобы только крестик закрытия формы оставался [biSystem] и в каком нибудь режиме типа bsDialog чтобы форму нельзя было ресайзить.
И еще один вопрос по TGroupBox , TRadioBox в линуксе не имееют обрамления, хотя в винде все ОК.
Пробовал использовать Tbevel, он не берет в себя дочерных компонент, приходиться извращаться.

[Павел Ишенин]

Это зависит от оконного менеджера. Lazarus честно передает параметры окна, но не все оконные менеджеры это обрабатывают. Какой linux? Какой оконный менеджер?

[alexmai]

linux SUSE 11, что касается менеджеров, то это все про KDE , пробовал в GNOM TGroupBox TRadioBox - ОК, но а BorderStyle то хоть в рунтайме работает.
Так что выходит в Кедах ничего нельзя сделать ?

[Logo]

В отличии от Windows, все UNIX подобные системы имеют огромное количество оконных менеджеров, это не только KDE и Gnom. Но и почти каждый менеджер имеет множество тем, которые могут изменять внешний вид до неузнаваемости, в том числе и исключать или добавлять некоторые из компонентов. Поэтому и получается, что свойсво в одном менеджере-теме не работает, а в других оно на месте. Конечно, можно все это переписать, но этого не стоит делать, так как программа в определенной среде будет выглядеть неестественно.

Что теперь методом научного тыка искать что работает, что нет ?

Да. Если Вы хотите, чтобы ваше приложение имело пристойный вид на всех менеджерах и темах, Вам необходимо иметь хоть часть их в своем арсенале и проверять, как оно работает. Правда это только по началу напрягает. После определенного периода работы все нюансы запоминаются и уже в большей степени ориентируешься своим воображением.

[alexs]

alexmai
Использовать свои темы в программе, отличные от тем которые сейчас установленв в ОС - неочень хорошая идея.
надо стараться максимально быть интегрированным в десктоп - поэтому не надо впендриваться и рисовать свой супер-пупер интерфейс
просто в вашем окружении он может и буде хорошо смотреться - но если у пользователя цветовая гамма хоть чуть-чуть отличается от вашей - могут получиться большие ляпы.

[Павел Ишенин]

пробовал в GNOM ...., но а BorderStyle то хоть в рунтайме работает.

При работе в дизайнере реакция на изменение BorderStyle умышлена отключена, т.к. в дизайнере всегда должно быть доступно изменение размеров формы растягиванием, и пр. Кроме прочего при изменении BorderStyle часто надо пересоздавать окно, а следовательно и все контролы на нем.

[alexmai]

В отличии от Windows, все UNIX подобные системы имеют огромное количество оконных менеджеров, это не только KDE и Gnom. Но и почти каждый менеджер имеет множество тем, которые могут изменять внешний вид до неузнаваемости, в том числе и исключать или добавлять некоторые из компонентов. Поэтому и получается, что свойсво в одном менеджере-теме не работает, а в других оно на месте. Конечно, можно все это переписать, но этого не стоит делать, так как программа в определенной среде будет выглядеть неестественно.

Что теперь методом научного тыка искать что работает, что нет ?

Да. Если Вы хотите, чтобы ваше приложение имело пристойный вид на всех менеджерах и темах, Вам необходимо иметь хоть часть их в своем арсенале и проверять, как оно работает. Правда это только по началу напрягает. После определенного периода работы все нюансы запоминаются и уже в большей степени ориентируешься своим воображением.

Ну уж не надо выдавать желаемое за действительное, при моей памяти всего два вменяемых оконных менеджера, KDE и GMOM? но на разных библиотеках собраны.

Что касается моего вопроса, то здесь вопрос принципиальный.
Если в общепринятых оконных менеджерах не работает приличное количество компонент,
а тем более их свойств и методов,
уберите, замените на те, что будут работать на базовых иксах KDE и GNOM.
А ОБМАН девелопера, в виде ЛЖЕ- компонент и их свойств в opensource системах НЕ ДОПУСТИМ.
О какой кроссплатфрменности идет речь если в разных иксах невозможно одинаково управлять кнопочками в заголовке или правильно отобразить рамку вокруг RadioBox.
Такие мелочи , дают возможность петухам от java и c++ кукарекать, что lazarus дерьмо, хотя сами в нем давно уже.
И не надо списывать недоработки на UNIX и другие ОС, а то так Lazarus умрет толком не разродившись.

[Иван Шихалев]

при моей памяти всего два вменяемых оконных менеджера, KDE и GMOM? но на разных библиотеках собраны.

Ни один оконным менеджером не является и может работать с разными WM... Учить матчасть!

[Attid]

надо стараться максимально быть интегрированным в десктоп - поэтому не надо впендриваться и рисовать свой супер-пупер интерфейс

кста ты часто на форуме, то тут то там хитрости интерфейса описываешь, якори, выравнивая, авторазмер и т.д.
может небольшую статейку "кросплатформенный(кросвиджетный) интерфейс" нарисуешь с картинками или в блог. хотя можешь и отдельной темой в форуме, я её подвешу чтобы не терялась ?

[alexmai]

при моей памяти всего два вменяемых оконных менеджера, KDE и GMOM? но на разных библиотеках собраны.

Ни один оконным менеджером не является и может работать с разными WM... Учить матчасть!

Logo писал(а):
В отличии от Windows, все UNIX подобные системы имеют огромное количество оконных менеджеров, это не только KDE и Gnom. Но и почти каждый менеджер имеет множество тем, которые могут изменять внешний вид до неузнаваемости, в том числе и исключать или добавлять некоторые из компонентов. Поэтому и получается, что свойсво в одном менеджере-теме не работает, а в других оно на месте. Конечно, можно все это переписать, но этого не стоит делать, так как программа в определенной среде будет выглядеть неестественно.

Ну и к чему эти пальцы веером, я ответил человеку в тех понятиях которых он определил мне в посте, глвное что друг друга поняли, лучше что-нибудь внятное по сути подскажите, а тоя тоже много чего уже забыл за 31 год программирования, о чем вы никогда не узнаете.

[B4rr4cuda]

/offtop

Ну уж не надо выдавать желаемое за действительное, при моей памяти всего два вменяемых оконных менеджера, KDE и GMOM? но на разных библиотеках собраны.

Не надо, не надо. Самый вменяемый менеджер - ion3. Попробуйте убедить меня в обратном .
/offtop

[Sergei I. Gorelkin]

"Как в виндовс" оно может работать только с тем оконным менеджером, который специально написан "чтобы быть как виндовс". И то, например, аналога biHelp в стандартных протоколах ICCCM нет по определению, поэтому менеджер может поддерживать его только через свой собственный протокол, а это означает, что программа должна в свою очередь быть заточена под данный конкретный менеджер.

p.s. Не стреляйте в пианиста, он играет как умеет (c)

[Logo]

Ну уж не надо выдавать желаемое за действительное, при моей памяти всего два вменяемых оконных менеджера, KDE и GMOM? но на разных библиотеках собраны.

Если точнее, то GTK, QT-4, Carbon, Win32/64. Тоесть, пока 4 работающие платформы под Lazarus. Но проблема в том, что, например, для GTK есть много тем и эти темы не обязательно могут иметь все возможные компоненты. Отсюда и получается, что что-то не работает, не говоря уже о разновидности всех этих виджетсетов.

Что касается моего вопроса, то здесь вопрос принципиальный.
Если в общепринятых оконных менеджерах не работает приличное количество компонент,
а тем более их свойств и методов,
уберите, замените на те, что будут работать на базовых иксах KDE и GNOM.
А ОБМАН девелопера, в виде ЛЖЕ- компонент и их свойств в opensource системах НЕ ДОПУСТИМ.

Возможно Вы и правы, в том плане, что нужно создавать платформозависимый Object inspector и панель компонент, но я не могу согласиться, что актуальны только KDE и GNOM. Например, для кассового терминала вовсе не нужно иметь громоздкий KDE или GNOM....
А вообще, то это напрягает только при начальной работе, сам это испытывал после шестилетнего перерыва. Сейчас привык

О какой кроссплатфрменности идет речь если в разных иксах невозможно одинаково управлять кнопочками в заголовке или правильно отобразить рамку вокруг RadioBox.
Такие мелочи , дают возможность петухам от java и c++ кукарекать, что lazarus дерьмо, хотя сами в нем давно уже.
И не надо списывать недоработки на UNIX и другие ОС, а то так Lazarus умрет толком не разродившись.

О реальной кроссплатфрменности.
Java действительно даст очень близкий по виду интерфейс, хотя под виндовс он будет виндовсовский, а вот под *nix он будет явовский, но детали будут присутствовать все.
А вот о С++ не надо. Кроме как QT-4 ничто не объединит разные платформы, но и Lazarus это умеет.

[Иван Шихалев]

нужно создавать платформозависимый Object inspector и панель компонент

MSE, насколько я помню, не завязан на виджеты. Вот он должен работать одинаково, а от Lazarus'а этого требовать не стоит.

[Vadim]

Ничего не поделаешь, теперь придётся создавать новый кроссплатформенный виджет - Лазарусджет.