Xlib: Fallback to first display if app:main_display() doesn't match any

[tomas]

I have a dual monitor setup and in my case the reported x/y are: (0,42) and (1920,0). This was causing main_display() to not return any values. With this change, we make sure to always return a value even if no displays are found at (0,0)

[capr]

The problem with this is that displays[1] is a random display, which means that using main_display() might cause the app window to jump from screen to screen every time it starts. A solution would be to always sort the displays list, then we could consider displays[1] as a stable fallback. What do you think?

[tomas]

Makes sense! 👍

[capr]

Btw, is your task bar on the top side? Because (0, 42) looks suspiciously like it should be (0, 0) but it doesn't include the task bar, so maybe there is a bug somewhere after all.

[tomas]

Nope, task bar is at the bottom. The screens are a bit misaligned because one is bigger than the other (so I offsetted them to make up for the difference).

[tomas]

By the way, now that I have your attention: how many GUI libs/toolkits are there in Luapower? It seems that there are plenty of options, but there's very little documentation explaining their differences. I mean:

• https://github.com/luapower/nw (this repo)
• https://github.com/luapower/ui
• https://github.com/luapower/cplayer
• https://github.com/luapower/imgui

Would you mind shedding some light? :)

[capr]

Yeah, sorry about that :) I will write a long post in two days about the dev progress from the last 6 months (which is roughly the time I started working on luapower again after a long hiatus). For now you can get a clue about the libs from the homepage, eg. see the Unsupported category. Anyway, here's a quick review on the UI libs:

• nw is the "native windows" lib, aka the OS interface for windows and input (no widgets). It's analogous to SFML, GLFW, SDL, etc. Everything related to UI is based on it.

• cplayer is the first UI lib I wrote. It's a procedural "graphics player" like processing. It's aim is to provide the simplest possible API that would allow making quick demos and interactive tests of other libs. Most demos are done with this library. It has many widgets but not enough to make a full app. It was abandoned in favor of ui.

• imgui was an attempt to make a complex UI lib IMGUI-style. It was abandoned in favor of ui, which is a RMGUI.

• ui is the lib I'm working on right now. It's in heavy development. Right now it has css, transition animations and layers (which incorporate mouse events, hit testing, positioning, z-order, clipping, hot/active logic, drag&drop, background, borders, shadows, etc..). Widgets and constraint-based layouting is are coming up next.

Hope this helps :)

[tomas]

It does! Thanks. Still, it wouldn't hurt to have some info on each project's repo, at least mentioning the deprecated status in those that apply.

Any chances I can try some demo of your new ui lib, by the way? Sounds pretty cool.

[capr]

Not yet. Just ui_demo.lua but that changes every day (eg. currenly it tests drag & drop... tomorrow, who konws?). In order to make a good demo showcasing and testing all the features I need a UI lib first... just one of those annoying chicken and egg problems :)

[tomas]

I see. Considering you've already build two other UI/widget libraries, you muist have a few bits of code you can reuse. :)

[capr]

Not much luck on that one :) The RMGUI and IMGUI approaches are very different and the scope of the libs is very different too. IMGUI is a procedural approach so if you hardcode both the appearance and the behavior of the widgets you can make one really fast with very little code (see cplayer/*.lua). OTOH the RMGUI approach is OOP: more complex but can be made very extensible in both aspects. Eg. the grabbing rectangle of a scrollbar is a layer, so you can apply any styling to it that a layer supports: custom background, border, even custom content (attach sub-layers), etc. The scrollbar is itself a layer, so you can eg. rotate it as a whole (which is how you make a vertical scrollbar out of a horizontal one without writing code).

[tomas]

Any chance you could merge this?

[capr]

Hi tomas, when there's no main display, I don't think the library should make a random choice for the user here since there is no one good choice. Wouldn't it be clearer if you just call app:main_display() or app:displays()[1] ? If X11 had the notion of a main display that would solve the problem, but alas, I couldn't find that API.