о чем спор?

У кого писька длинее как обычно

Программирование и уж тем более цсс тут вообще не при чем

в qml ведь стили задаются почти также как в CSS

В qml стили это свойсва обекта, и поменять их можно только наследованием

можно ышо через js но это вариант не относится к декларативщине

А через c++ нельзя?

(Можно)

аа, с этой позиции... тут да. В css этого не хватает, даже всякие препроцессоры запили типа sass

А через c++ нельзя?

Хз, извращением не занимался, на c++ логика, на qml морда, зачем мешать?

Что если я скажу что в qml нету никаких свойств, есть только объекты

у обекта есть свойства

И их можно так же как из qml создавать из це++

В том числе динамически

Это как xaml в wpf

И их можно так же как из qml создавать из це++

Спор ради спора? начиналось с css

В qml стили это свойсва обекта, и поменять их можно только наследованием

Свойства объекта или класса?

Бывает в процессе метания говна кто-то что-то интересное говорит

Спор ради этого

Если объекта то причем там наследование, и почему его свойство имутабельно

Свойства объекта или класса?

Обекта скорее, не имутабельно - но поменять наподобии как в ксс - селекоторами низЯ

Т.е там просто не завезли селекторы?

У тебя есть интерпретируемый язык, как жс, только инструкции в нем это создание объектов гуя

потому как они нах там не нужны

И работа как в плюсах через свойства?

Ну а как ты задашь стиль для всех кнопок например в одном из окон

Создашь объект qcolor

Создашь файл с переменными как вариант

Ссылку на его id сделаешь

Определишь глобальную переменную

И компоненты должны будут брать цвет из неё

Пиздос

Каждый компонент?

Создашь снопку заднных цветов - и её будешь использоватьь

Должен сам брать?

А нехуй много компонентов делать чтобы они потом тормозили как в хтмл

Для стандартных котролов есть *Style компоненты

например Button - ButtonStyle

Ну да, так гораздо проще чем в цсс

Это на словах страшно

А знаешь, что ещё было б проще? Можно было б по компоненту на свойство стиля для каждого объекта ButtonColor, ButtonPosition

Кайф был бы

Главное попиздеть =)

Вообще для виджетов в qt есть qss, аналог css

это для c++

Селекторы по классам и объект нейм

На qml у меня толькоигрушнчные проекты

Хз что там

Там ограниченый сабсет

Ограниченный сабсет для ограниченного языка

Для ограниченных прогаммистов

Qml удобен там где у одной проги - могут быть разные морды

Как раз таки с разными стилями

http://wiki.qt.io/Qml_Styling

Весь кайф в конце

Вложенные стили

ну это на любителя

s (i.e. border.width.normal)

Qml удобен где надо простенькую анимацию наговнякать

Qml удобен где надо простенькую анимацию наговнякать

И это тоже

Есть правда вещи которые ... чтобы обрабатывать мышку или тач нужно создавать MouseArea и натягивать её на обьект

Что-то мы ушли от темы чата

А где удобен раст?

We’ve seen memory usage of using rustc to drop 5-10% with this change

пиздоболы, пока что наоборот

А где удобен раст?

На сервисах

Но го же удобнее?

С одной стороный порой рас много словен, с другой стороны - заставляет писать правильно

Менеджит память, масштабируется на ядра

Но го же удобнее?

Мне не нравится го, язык хороший, но програмить на нем не вкуйф

Тебе повезло работать где можно выбирать инструмент

Я тож так думаю

Насчет го напишу сейчас

Допустим есть у меня сервис готорый должен оддавать все ответы в Json В виде {"code":"CODE", "data":...} для одиночных записей {"code":"CODE", "data":{}} для списков {"code":"CODE", "data":[]} В расте я делаю структуру #[derive(Debug, Serialize)] struct APIReply<T> { code: String, data: T }

потом pub fn api_return_object() { let mut obj = Object::new() { ... } let response = APIReply { code: String::from("OK"), data: obj }; let mut reply = json_reply(StatusCode::Ok, ""); reply = reply.with_body(serde_json::to_string(&response).unwrap()); reply }

Для списка так pub fn api_return_object_list() { let mut response = APIReply { code: String::from("OK"), data: Vec::new() }; let mut obj = Object::new() { ... } response.data.push(obj); let mut reply = json_reply(StatusCode::Ok, ""); reply = reply.with_body(serde_json::to_string(&response).unwrap()); reply }

Ну опустим проверку ошибок, как такое сделать в Го?

Ну без генериков придётся либо через interface{}

За счет дженериков я не беспокоюсь о многих вещах, у меня есть абстракции - в го нужно каждый случай описывать ручками

Либо через свою структуру для каждого типа

Но го же удобнее?

Я ответил на твой вопрос?

Обычно сервис это что-то посложнее