5 ms·

This: "Hello, <bold blue size=16>Nana C++ Library</>" looks a bit strange. Looks like XML but it is definitely not (the </> construct for example). If the pur

This: "Hello, <bold blue size=16>Nana C++ Library</>" looks a bit strange. Looks like XML but it is definitely not (the </> construct for example). If the purpose is to provide inline styling then I would use something richtext alike: "Hello, [B S16 C#00F]Nana C++ Library[bsc]" But split on HTML (semantic, structure) and CSS (styling) is anyway better for many reasons.

taeric 8y ago
Is it really better to split on semantic/structure and styling? Specifically, do we have evidence that that is the case? I know we certainly seem to like it. Quite often, any supposed advantages of it are never realized. And instead we grow into rather heavy solutions that are so painful to work with we reach for the next framework.
- c-smile 8y ago
  "Is it really better to split on semantic/structure and styling?" When you need to show the same UI on different devices (desktop, mobile, OSes) and media (screen, high-dpi-screen, printer) you will come up to the need of separate style definition entity almost immediately. Like this: "Hello, <bold blue size=16>Nana C++ Library</>" Should be just this "Hello, <em>Nana C++ Library</em>" and styles for the emphasis that can be different for each platform. Even for the same OS and user session you will need different style systems if you want to support dark and light theming for example. Yet having UI nailed down to pixels grids (<bold size=16>) is a path nowhere.
  - taeric 8y ago
    This is an appealing argument. But most of us don't actually have that. Worse, many attempts have shown greater success with just minimal styling and/or multiple versions.
    - keerthiko 8y ago
      Another important consumer-end feature of splitting style/structure is it allows clients to have custom styles, accessibility-oriented styles, by just swapping out the "styling" content of an application/page without needing to swap out or inject into the UI structure/code. The benefits to developers are more "trade-offs", but I think it generally is a better raw framework to work in without significant IDE-assistance to do development.
      - taeric 8y ago
        This is an important feature that, statistically, nobody uses. Worse, I challenge you to try it on a major site. :( Again, I like the argument. I just feel there is more taking about it, than benefits from it. Empirically, it just falls flat.
        keerthiko 8y ago
        You are probably right. But also statistically, "nobody" is disabled or needs accessibility features. That's a poor argument for running in the opposite direction from providing them. Benevolent systems cater to the least powerful user, not the median user, and I think it's good to support benevolent systems wherever possible, because businesses are naturally biased against benevolence.
        taeric 8y ago
        I challenge that. There are fewer disabled users, true. Statistically, they do exist. They far outnumber folks that use this feature.
    - c-smile 8y ago
      > don't actually have that Not clear what exactly. > with just minimal styling and/or multiple versions. If an application has simple UI that can use predefined and quite limited set of system UI elements then you probably don't need to style anything. But this is not the case of the library we are discussing.
  - Const-me 8y ago
    > you will come up to the need of separate style definition entity almost immediately Not necessarily. As always with software design, there’re tradeoffs involved. Separate styles work when the stuff you’re styling is content to consume, not rich GUI to edit/produce. For rich GUI that works well on every platform you need different structure, not just different styles. Separate styles work when the devices are not too different. If they are very different, like PC and smartwatch, you probably need different structure even for readonly content. There’re frameworks/design patterns, like MVVM for XAML, MVC for iOS and old-school web, where you can replace complete views while reusing the rest of the app.
    - c-smile 8y ago
      > For rich GUI that works well on every platform you need different structure, not just different styles. Why do you need such "modern C++ GUI library" then? Check my Sciter Notes. Screenshots of the application for each platform are on its frontpage: https://notes.sciter.com/ https://notes.sciter.com/ This application uses the same UI definitions on any platform (https://github.com/c-smile/sciter-sdk/tree/master/notes/res https://github.com/c-smile/sciter-sdk/tree/master/notes/res) and the same C++ code.
      - pknopf 8y ago
        Is the source for Sciter available?
        neurocline 8y ago
        It looks like it’s on Github (link from the Sciter Downloads page).
        pknopf 8y ago
        It looks like it's just pre-compiled libs.
      - Const-me 8y ago
        > the same UI definitions on any platform Very nice library! But you only support PCs. You have same structure, and same UX (mouse+keyboard, relatively large screen) on all of them, you only need to adjust for DPI scaling, and for window resize. About hardcoded pixel sizes, sometimes they’re OK. Apple did that in iOS, worked well for them. When they released iPhone 4, they just doubled the DPI. And when they released iPad, they made developers replace complete views and it made sense because it was much different UX. I’m not saying that library is good. Apple has separate UI markup language, and they have decent UI designer in XCode for that. The feature is IMO required for a modern GUI framework and it’s missing in Nana. Also, GPU-based rendering is nice to have nowadays, see MS XAML or Google Flutter. I once needed to create rich GUI for embedded Linux app on top of essentially raw hardware, drm, kms, gles. I’ve compiled C shared library exposing some wrappers around NanoVG API https://github.com/memononen/nanovg https://github.com/memononen/nanovg then implemented touchscreen input, controls, styles and animations in C# using .NET core. Worked well for my requirements.
  - qPCR4vir 8y ago
    When you need to show the same UI on different devices (desktop, mobile, OSes) and media (screen, high-dpi-screen, printer)?
pavlov 8y ago
The anonymous end tag </> exists in SGML, the mother of XML. Maybe that’s the source of inspiration.
oaiey 8y ago
They also lost me at that moment. I can understand high level representation like qml and xaml... but mixing them like that into plain c++ and also with this XML/sgml/HTML thingy ... Smells wrong.
- qPCR4vir 8y ago
  What is bad with mixing them like that into plain c++? Why may be better to have external tools?
qPCR4vir 8y ago
Is not <bold blue size=16>Nana C++ Library</> easier to read/write than [B S16 C#00F]Nana C++ Library[bsc] (especially for a c++ programmer)?

taeric 8y ago

Is it really better to split on semantic/structure and styling? Specifically, do we have evidence that that is the case? I know we certainly seem to like it. Quite often, any supposed advantages of it are never realized. And instead we grow into rather heavy solutions that are so painful to work with we reach for the next framework.

c-smile 8y ago
"Is it really better to split on semantic/structure and styling?" When you need to show the same UI on different devices (desktop, mobile, OSes) and media (screen, high-dpi-screen, printer) you will come up to the need of separate style definition entity almost immediately. Like this: "Hello, <bold blue size=16>Nana C++ Library</>" Should be just this "Hello, <em>Nana C++ Library</em>" and styles for the emphasis that can be different for each platform. Even for the same OS and user session you will need different style systems if you want to support dark and light theming for example. Yet having UI nailed down to pixels grids (<bold size=16>) is a path nowhere.
- taeric 8y ago
  This is an appealing argument. But most of us don't actually have that. Worse, many attempts have shown greater success with just minimal styling and/or multiple versions.
  - keerthiko 8y ago
    Another important consumer-end feature of splitting style/structure is it allows clients to have custom styles, accessibility-oriented styles, by just swapping out the "styling" content of an application/page without needing to swap out or inject into the UI structure/code. The benefits to developers are more "trade-offs", but I think it generally is a better raw framework to work in without significant IDE-assistance to do development.
    - taeric 8y ago
      This is an important feature that, statistically, nobody uses. Worse, I challenge you to try it on a major site. :( Again, I like the argument. I just feel there is more taking about it, than benefits from it. Empirically, it just falls flat.
      - keerthiko 8y ago
        You are probably right. But also statistically, "nobody" is disabled or needs accessibility features. That's a poor argument for running in the opposite direction from providing them. Benevolent systems cater to the least powerful user, not the median user, and I think it's good to support benevolent systems wherever possible, because businesses are naturally biased against benevolence.
        taeric 8y ago
        I challenge that. There are fewer disabled users, true. Statistically, they do exist. They far outnumber folks that use this feature.
  - c-smile 8y ago
    > don't actually have that Not clear what exactly. > with just minimal styling and/or multiple versions. If an application has simple UI that can use predefined and quite limited set of system UI elements then you probably don't need to style anything. But this is not the case of the library we are discussing.
- Const-me 8y ago
  > you will come up to the need of separate style definition entity almost immediately Not necessarily. As always with software design, there’re tradeoffs involved. Separate styles work when the stuff you’re styling is content to consume, not rich GUI to edit/produce. For rich GUI that works well on every platform you need different structure, not just different styles. Separate styles work when the devices are not too different. If they are very different, like PC and smartwatch, you probably need different structure even for readonly content. There’re frameworks/design patterns, like MVVM for XAML, MVC for iOS and old-school web, where you can replace complete views while reusing the rest of the app.
  - c-smile 8y ago
    > For rich GUI that works well on every platform you need different structure, not just different styles. Why do you need such "modern C++ GUI library" then? Check my Sciter Notes. Screenshots of the application for each platform are on its frontpage: https://notes.sciter.com/ https://notes.sciter.com/ This application uses the same UI definitions on any platform (https://github.com/c-smile/sciter-sdk/tree/master/notes/res https://github.com/c-smile/sciter-sdk/tree/master/notes/res) and the same C++ code.
    - pknopf 8y ago
      Is the source for Sciter available?
      - neurocline 8y ago
        It looks like it’s on Github (link from the Sciter Downloads page).
        pknopf 8y ago
        It looks like it's just pre-compiled libs.
    - Const-me 8y ago
      > the same UI definitions on any platform Very nice library! But you only support PCs. You have same structure, and same UX (mouse+keyboard, relatively large screen) on all of them, you only need to adjust for DPI scaling, and for window resize. About hardcoded pixel sizes, sometimes they’re OK. Apple did that in iOS, worked well for them. When they released iPhone 4, they just doubled the DPI. And when they released iPad, they made developers replace complete views and it made sense because it was much different UX. I’m not saying that library is good. Apple has separate UI markup language, and they have decent UI designer in XCode for that. The feature is IMO required for a modern GUI framework and it’s missing in Nana. Also, GPU-based rendering is nice to have nowadays, see MS XAML or Google Flutter. I once needed to create rich GUI for embedded Linux app on top of essentially raw hardware, drm, kms, gles. I’ve compiled C shared library exposing some wrappers around NanoVG API https://github.com/memononen/nanovg https://github.com/memononen/nanovg then implemented touchscreen input, controls, styles and animations in C# using .NET core. Worked well for my requirements.
- qPCR4vir 8y ago
  When you need to show the same UI on different devices (desktop, mobile, OSes) and media (screen, high-dpi-screen, printer)?

pavlov 8y ago

The anonymous end tag </> exists in SGML, the mother of XML. Maybe that’s the source of inspiration.

oaiey 8y ago

They also lost me at that moment. I can understand high level representation like qml and xaml... but mixing them like that into plain c++ and also with this XML/sgml/HTML thingy ... Smells wrong.

qPCR4vir 8y ago
What is bad with mixing them like that into plain c++? Why may be better to have external tools?

qPCR4vir 8y ago

Is not <bold blue size=16>Nana C++ Library</> easier to read/write than [B S16 C#00F]Nana C++ Library[bsc] (especially for a c++ programmer)?