Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

tomas
Copy link

@tomas tomas commented Mar 29, 2018

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
Copy link
Member

capr commented Mar 29, 2018

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
Copy link
Author

tomas commented Mar 29, 2018

Makes sense! 👍

@capr
Copy link
Member

capr commented Mar 29, 2018

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
Copy link
Author

tomas commented Mar 30, 2018

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).

image

@tomas
Copy link
Author

tomas commented Mar 30, 2018

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:

Would you mind shedding some light? :)

@capr
Copy link
Member

capr commented Mar 30, 2018

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
Copy link
Author

tomas commented Mar 30, 2018

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
Copy link
Member

capr commented Mar 30, 2018

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
Copy link
Author

tomas commented Mar 30, 2018

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

@capr
Copy link
Member

capr commented Mar 30, 2018

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
Copy link
Author

tomas commented Oct 5, 2021

Any chance you could merge this?

@capr
Copy link
Member

capr commented Oct 6, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants