Skip to content
This repository has been archived by the owner on Dec 2, 2019. It is now read-only.

Offtopic: Single-header window management and layouting library #323

Open
dumblob opened this issue Jan 13, 2017 · 0 comments
Open

Offtopic: Single-header window management and layouting library #323

dumblob opened this issue Jan 13, 2017 · 0 comments

Comments

@dumblob
Copy link
Contributor

dumblob commented Jan 13, 2017

For about 10 years I'm repeatedly running into the issue of window management and layouting (Windows graphical shell, unix X11 windowing, Mac OS X windowing, in-application windowing like in Nuklear, mobile systems windowing, etc.). There are plenty of window managers, window managing applications, layouting algorithms, guidelines for mobile-friendly windowing, standards (EWMH, ICCCM, etc.) and related stuff. But it's everything a mess, wildly differing, not multiplatform, not transferable, too dynamic (what works now will soon stop working), each solution offers only a subset of the needed/expected functionality, and most of them are mutually incompatible (combining of several existing solutions doesn't work at all or not well enough).

And because I'm convinced, that windowing functionality shouldn't be part of a GUI library and at the same time should be fully multiplatform, I recently got an idea of a single-header library providing a minimalistic interface for the following three domains of functionality.

  1. Means for setting high-level abstracted behavior and properties and for each also it's defaults (e.g. new windows will appear there and there and will have this and this frame with these and these attributes).
  2. High-level abstracted triggers of all kind (e.g. a new window appeared and you can access it through this pointer/structure/object/...).
  3. Interfaces for several wide-spread standards (EWMH, ICCCM, etc.). Inclusion/exclusion of these shall be configurable through similar means as NK_INCLUDE_* in Nuklear.

(with high-level and abstracted I mean mostly things initiated by the user and by to-the-user-visible issuers like some remote or scheduled commands etc.)

What do you all think about this? Would you use such a library or rather stick with an own half-baked solution?

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

No branches or pull requests

1 participant