Not sure if you know this but for the benefit of anyone reading this in Discourse you can watch a tag and be notified of all new posts in that tag. So for example if you go to Topics tagged scenic and click on the circle in the upper right you can choose “watching first post” and be notified via email of all new posts with that tag (scenic) in this example.
axelson
Scenic Core Team
OvermindDL1
Sounds like you have a PR in mind to expose that functionality from wx itself. ^.^
Pretty easy to make new components in Wx as well, old style code but it works.
Features get added when someone needs them and thus adds them. 
Honestly I’d just say it should all be based on Qt or so now, it’s OGL accelerated, fully themeable or can look like the OS, etc… etc… Now if only it’s license wasn’t quite as horrible. ^.^;
Except they are varied and most are incompatible in how they work as well. Like take Qt, there is a GTK hoister that themes GTK apps to look QT’ish, but it’s not perfect. The best thing to do is to use the native platform primitives for the given windowing system, which on, say, my system is Qt, on others is GTK, on Windows is whatever-new-flavor-of-the-week, and that is all way way too much work, and that would just be on ‘using’ them, however to be able to support their themes would be even more work as you are essentially rewriting their drawing commands for them all. I tend to prefer Qt personally as it does the best among them all, even with its horrible license. ^.^;
Regardless, the BEAM is not made for making desktop apps. Sure you can shoehorn it in but it never works as well as an actual native app. The reason scenic and such exist is for embedded systems that don’t have their own interfaces. If it is a normal desktop, just write the GUI part in a normal language.
Based on what you are wanting I’d say you should make it and then publish the library on Hex.
1
Eiji
I’m not sure about tray icon (look Plasma custom tray), but I would like to not add notifications support to scenic. I wanted say that I did not found anything working around it. :wx comparing to :scenic does not give me any benefit (of course :wx is bigger, have more components etc. but this would by simply changed in future).
I would like to write some PRs, but I’m focused on one job, preparing for next one, on linkedin someone again asked me if I’m ok to work and finally I have almost finish one library from December, but can’t find a time to finish it properly. 
Here goes again :wx vs :scenic, but with Qt in place of :wx. scenic is definitely my favorite now and I don’t think it would change easy. Qt have options for themes, but as said only for its own themes. Look that oxygen and breeze themes have their separate GTK+ versions. At end I would like to see an settings page when you can browse for current theme, installed themes and themes from some repositories. With that end-user could decide which theme and behaviour he/she expects.
I have tried to find some custom window managers for Windows. I have hope that KDE team would make a stable kwin there, but it does not looks like a priority for them. I always want to write GUI apps for all OS and distributions and simply don’t care about Windows-like limitations. You probably feel same - at least I though that when you said about <alt> + mouse actions. Maybe for others it’s not important - for me it could be probably same, but once you tried it you would fall in love and you would like to have similar behaviour everywhere. Unfortunately some people are forced to use Windows which as said have too more limitations.
I’m not sure if you got it. For simplest example just take a look at documentation:
Except :radius in Additional Styles we have 3 other options: active, background and text. What I want is to just parse some theme files, read all available theme information and simply pass them to scenic in previous specified format. The biggest work (at least for me - i.e. anyone who did not worked with OpenGL previously) is to extend drawing code to support new options.
Of course some themes could be hard to scrape, but I did not said that we need all right now. I would like to firstly make research, create a final list of all possible theme options and add support for let’s say GTK+ theme files. Later we can extend and extend it by for example add option to apply theme from remote repository. Qt for me is even more worse than GTK+ - at least GTK+ allow custom controls in titlebar.
Sorry, but I did not get. With few steps we could make scenic (or its fork if it’s really not priority for @boydm) much more powerful than other GUI libraries. As said for example drawing in titlebar, drawing custom titlebar did not changed in years there - no matter how many developers asked for it. It have no sense for me to force using GTK+ or Qt if at end I would need to write custom OpenGL code to draw my own components which scenic is doing already.
Heh, I would really like to do so. As said I have not enough time, but I have more funds in last time than I originally planned. For now I could spend ~500 USD every month and maybe even more in future. Unfortunately I can’t fund everything myself, so it’s why I have created this topic.
0
OvermindDL1
Qt allows those as well, a variety of KDE apps have those as such.
However, if all scenic exposes is radius/active/background/text then that is significantly not enough. GTK’s is very… CSS’ish. QT’s is an entire scripting language where you can quite literally do anything (it’s actually very succinct, I quite like this part of Qt).
With few steps? GUI libraries are some of the largest libraries out though… o.O
Even just getting hidpi right is amazingly painful. Then you have I18n, both in displaying of and accepting of. If you put in detailed theming support that is more than just simple property updates then that’s a huge thing on its own. Etc… etc…
I very much like native interfaces, that’s what I meant by the Alt+Click+Drag to move. When a program breaks that assumption of my interface it is really really irritating. And that is not just Alt+Click+Drag to move, I could bind it to Meta+MiddleClick+Drag to move, or Ctrl+RightClick to maximize or restore, etc… It is impossible to emulate all the abilities that the windowing system allow for, this is why it is important to actually ‘use’ the windowing systems interfaces rather than just drawing everything in OGL.
0
Eiji
Yeah, they are really big, but it should not scary anyone.
Look:
[font: :roboto, font_size: 24]
|> Graph.build()
|> Primitives.rect({@width, @height}, fill: {48, 48, 48})
The only thing here is that few values should be fetched from specified theme.
Yeah, that’s why I would like to change it.
Parsing CSS is not simplest thing, but it’s also not impossible for most developers. Especially when we have lots of parsing-related libraries to use and learn from.
Yeah, it is - I would like to have API for layout which would be rendered based on viewport resolution. Also painful does not mean it’s really hard. Basic things things like creating equivalent of Bootstrap (which is written in CSS) for scenic should not be really hard. Of course it requires lots of OpenGL code, so for me it would be really hard. However I believe that we could find some developers which are experienced in it.
Hmm, I though about it too. Should not be really hard. When writing details I would need to look again deep in scenic API and see how much things I would like to have in order to write i18n library for scenic-based apps.
I just want to fetch some properties from specified theme and update style properties based on them. Assuming that we will have code to fetch all information then the biggest work is … again OpenGL. Basically if there would be somebody which feels in OpenGL as well as I in Elixir then it should be pretty easy.
I would like to give a try creating frameless, fullscreen and transparent window which could simulate window manager behaviours. However I was not sure about it and it’s why I think that’s biggest 
for what I’m planning.
In short there are 4 biggest parts of my plans:
-
Scraping data - depends on theme files some are even really easy.
Again we do not need to have support for all exactly now. Harder themes could be delayed for later. -
OpenGLpart - it should not be a problem for someone experienced in this topic
Also again I did not had a chance to do anything bigger inOpenGL, so for me it looks hard. -
Reproduce window manager behaviours
This could be even skipped on compile time fornervesdevices. -
Introduce other API - not strictly related to
sceniclike system notifications, system sounds etc.
For me biggest priority are in order:
-
Research and
OpenGLwork based on results
In order to have everything prepared even if there is no scrapers for any theme files. -
Make
scenic(or its fork) work properly fromCLIfor end-user (instead of distillery releases). -
Add support for OS notifications, simple (icon + menu) tray icon etc.
Later maybe evenPlasma5 custom tray support. -
Add more components
-
Add i18n support
-
Add
sceniclibraries for themes and related -
Add not strictly related helpful libraries for GUI apps
Note:
For sure I don’t said that anything from my plans is “5 min” work. I just want to say that’s only a matter of time and funds to implement such things.
0
OvermindDL1
It’s still not CSS however.
And how do you determine that resolution? GTK doesn’t get it right at all, hence why it requires environment variable workarounds and so forth. Qt is one of the only things I’ve ever seen it get mostly right on linux and that’s only on wayland. X just doesn’t have the capabilities to let you know that information reliably, it wasn’t even a concept when it was created. Mac’s get it right 99% of the time, Windows fails on mismatched monitor DPI’s in most cases among others… It’s a world of pain if you want multiplatform hidpi and you aren’t using Qt.
Heh, i18n input is significantly harder than you’d expect… ^.^;
Displaying it isn’t bad, it’s the input that is a horror.
And if you are wanting to get that information from, say, GTK or QT or Windows themes then you have a dozen parsers there with a few interpreters and rewriting the rendering of each essentially from scratch. If you want it to feel native then you need to call the native API’s.
Simulate means it will feel as ‘off’ as even the most accurate SPA’s via PWA’s. A lot of things will not work right or at all.
Some are easy. All of the most-used ones are significantly hard except Window’s Registry parsing.
It’s hard, not because of OpenGL, but because of having to replicate the rendering of the native drawing calls, “that” is a significant amount of work.
At that point you are, quite literally, rewriting large swaths of every windowing system out instead of just calling the known interfaces…
Linux, Mac, and Windows (and android and iOS and etc…) all draw their interfaces via 3D calls now (whether OGL, EGL, Vulkan, or DX), the rendering is not hard, rewriting the drawing to look native is what is hard, incredibly hard.
Huh? Like render it’s gui in text or something?
Every OS has interfaces for these, don’t duplicate the functionality as then it will lose the controllability of it from the OS itself. Just call the interfaces.
Just as a note,but my Gut Reaction to the above is significantly more than $500 of work. $500 is less than 10 hours of work for even a basic job to do the same and 10 hours is no where near enough for this sheer scale of coding needed, even 10 months I don’t think is anywhere near enough to any significant degree, this would be a many-year project if you want it feeling native but rendered within scenic.
If you want to draw native GUI’s, why not make the native calls or use an abstraction around those (of which both wxWidgets and Qt both are) instead?
A big note from the OP:
Vivaldi uses Qt, that is why it is themeable and has proper i18n support.
Scenic absolutely rules on embedded devices, like Nerves builds, but if you want something feeling native on a desktop it is not suited for that and from how it is currently built I doubt it ever would be unless it starts wrapping a backend like Qt or so.
0
Eiji
yeah, but it’s really similar
It’s like CSS, but it has its own extra properties and calls like -gtk-scaled, but browsers do the same having just different prefix like: --webkit-*.
Ah, I see … My bad here - I forgot about DPI. Yes it’s painful, but it’s not impossible. Also if it’s not working in other GUI libraries then it’s just another point to not use them.
oh, can you please link or describe it a bit more?
Wow … I think that dozens is too much. Well I have used lots of GUI libraries in lots of languages, but the most popular are Windows themes, GTK+ (2 and 3) themes and Qt themes. I saw Plasma files which uses something like Linux config files. It’s popular format, so it should not be a problem. CSS-like format should not be a bigger problem as well. I’m not sure about Windows and MacOS, but as said we don’t need all now - the point is that to get all possible style attributes, implement them and later add scraper libraries.
I’m not sure what you are trying to say. Some things are not saved in theme files? For sure theme does not need to be 100% equal. The most important are input styles and colors specified in theme files (only later icons, sounds etc.). We should do a proper research and scrape as much as possible. If something is not possible to scrape then we would need to deal with it. It’s not a matter to do literally everything (like all possible components), but all things that are worth to. Some “super extra special” components which are only in one GUI library should not be really part of scenic - it’s like an edge case. Also nobody said that every component should be drawn in scenic only. That would be good if any developer could draw its own components and use fetched information from theme (let’s say button background color) for its own components.
You are first person I know which says good things about Windows registry. 
scenic is doing whole rendering anyway. It’s just a matter of new style options. Yeah, it would take long. Nobody said that drawing UI is easy. It’s another point to not leave developers with this problem and simplify it as much as possible.
How you would like to call known interfaces in OS which simply does not support them? Maybe I made a really bad research, but last time I was looking I did not found any good window manager for Windows. There was time I was looking for kwin for Windows, but even basics KDE apps have experimental support and probably they still have after few years. If calling OS interfaces would be so easy every app would do it.
For sure if you know a better way to make all of that working simpler then I’m open to your suggestions. I don’t believe that Qt would allow to do that without any extra (
) work . As said I had tried lots of libraries and I had problem with simplest example of tabs in titlebar. I don’t expect that any GUI library have already support for more advanced things.
I don’t want to reimplement everything of what you said. That’s definitely too much for me. Maybe in other words. Take a look at Plasma look and feel customization. I would like to basically scrape data from it and simply apply to OpenGL drawer without any 3D work.
Nope, sorry - I did not described it enough. When you have distillery then it generates release with its own command line options. I would like to have such release, but with my own options, my own --help and --version output etc.
Yeah, in notifications and tray icon we would need some NIFs here.
ok, I see … you think nobody else would be interested with adding funds? That would be a small problem then. btw. 50 USD / hour - nice. For now my salary is only 20 USD / hour.
Yup, now:
-
Can I use all behaviours of
kwininWindows XPbuild ofVivaldi? -
Please link me to library documentation for those custom tabs. I really want to simply call
renderTabs()in any app. Unfortunately I don’t believe it’s possible. -
Themes there are really, really limited to few colors. After adding more components (without extra styles) then
scenicwould be more configurable. -
At least for me
Vivaldiuses different cursor style. Again it’s just cursor style. Something small that nobody would care, but it’s actually hitting my eyes. Just because of such weird cases I want to let end-user to decide on which theme he/she want to use.
I like Vivaldi, but comparing to old versions of Firefox its also limited. It has much more GUI settings (comparing to Firefox preferences), but this could be solved before by simply adding one or two extensions (like Configuration Mania).
It’s possible to draw tabs in custom titlebar and even move it to any edge, but again every developer would need to do it on its own. One time as newbie I tried to look at source code of Chromium project and I just got lost. If any GUI app in Elixir is going to look like that without any change to split it in libraries then I don’t want to create GUI apps. Drawing everything on myself for every app would be even more painful.
Of course I’m open to any propositions, but everything already proposed is really limited by OS / specific window manager. None of solutions allows for example having Plasma 5 behaviours in Windows.
Sorry, but after reading your post few times I still don’t get why I need to use Qt in order to add for example shadow option to Button component when active, background and text options are already available without it. I’m sure it’s not simplest to write drawing code, but somehow it’s working in scenic already. Why we can’t simply extend that and instead of passing raw values simply read something like Linux config file and pass value from it …
Maybe I got something wrong, but after reading your post, adding such example shadow option looks like lots of weeks of work without any certainty of success. If you would look at example configuration file content I have quoted then you would see that it contains names and rgb values which should be really easy to scrape, pass and they would just need to be drawn. Of course it’s more than this config file, but it’s also not like writing OS code for 10+ years.
0
OvermindDL1
Hence why Qt should be used, I’m unsure of anything that does it as well as it does. ^.^
Remember that depending on how the user has their system setup then holding certain key combinations can cause a popup window to choose various characters, combinations of keys should print a different character altogether, typing a certain string of characters should all get combined into a single complex character (super common with asian scripts where typing a string of romanji gets turned into katakana or so), etc… etc… etc… Handling input manually without calling the native interfaces means this will not work and thus means they can’t type. Like this is a big problem on Steam, it’s never supported it and thus their messenger goes unused in certain areas of the world.
Not even remotely, windows has more than a dozen just right off the bat, from the base system colors stored in the registry to the Forms API themeing to far far more. Linux as well easily has over a dozen just across the more used windowing managers. Just handling windows themeing properly is a horrible task. Like how do you know if your edges should be curved or squared corners, what parts should be transparent and what shouldn’t, and how should they be transparent, is the transparency using the windows cloud shader/overlay, etc… etc… etc.. And that’s just a single aspect of the literal hundreds in windows themeing. And then you start getting into the windows theme plugins and that’s just Good Luck There. ^.^;
Okay, so windows says that the titlebar should be rendered as 20% transparent with a moving cloud opacity mapping that blurs what’s behind it and the title text the opacity comes up to 90% opacity in a circle around around it fading in? The UI calls all handle that for you, how would you expect to? Or on my wife’s computer that has an overlay effect of where the mouse is that shows a kind of purple star in the background chrome in windows or where she can drag multiple applications together into the same window and gets a firefox-like tabbed interface at the top on the titlebar of all the programs? How do you plan to handle that?
Lol, the Windows registry is not a bad ‘idea’, it’s just poorly implemented. ^.^;
That is why it is amazing on devices like Nerves systems and so forth. It is significantly less useful on a desktop, notice how most desktop usages of it (all that I’ve seen at least) focus on the opengl rendering aspect of it, not rendering a gui but more of a game.
Windows ‘window manager’ is not easy to replace, not even sure how, but the one it has is actually intensely powerful, far more so than most people realize, it’s also very crufty and supports all kind of backwards compatible things as well, and programs using only the older interfaces tend to look very ‘old’ as well, it makes the programs look very non-fitting, where the newer interfaces are actually incredibly powerful and complex.
How to call the known interfaces is like with any other system, you abstract it out, like Qt has already done that work for you even with much of the newest Windows API’s, and things like wxWidgets are significantly older in comparison, it looks like it belongs to Windows 98 rather than Windows 10.
That Qt couldn’t do what?
Tabs in titlebar is a simple thing? o.O
Usually the OS itself owns the titlebar, you have to tell the OS not to render it itself so you can render it instead, but in doing so you lose the abilities of the OS. Even wxWidgets, GTK, and Qt all support setting that flag so you can then render it yourself, but in rendering it yourself you are not going to render it like the user expects it to be rendered to match the OS. Like on mine or my wife’s computer if you don’t let the window manager handle the titlebar than we lose the capability to combine that program window with other program windows in a single tabbed window. That is very bad user interface. At least chrome and firefox have the option in their settings to let the OS handle the titlebar so we get that ability back but if some user program doesn’t than that’s just infuriating, plus losing the other features on the titlebars from additional buttons, shading (‘minimizing’ the window to become “just” a titlebar), etc… etc…
Heh, just taking Plasma alone as the theme engine is easily the most complex of them all. Theme scripts can literally render anything in any way that they want. Supporting that means rewriting the Qt theme interpreter engine, which means supporting javascript, python, and native binaries at the very least as those are the 3 built-in supported languages/interfaces and all 3 are heavily used. Plasma absolutely blows everything else away in its themeability as a window manager. I quite literally have a clock to the left of my shade/minimize/restore/close buttons in every app that shows the time in a 2-line ISO format, and I just realized how hard that tiny little feature would be to do in any other windowing manager. That’s even ignoring the fact that my windows ‘are’ 3d constructions here, I can even flip them around and some applications even render different things on the backsides (I wish that feature were used more).
You can include a wrapper script in distillery for that.
I’d doubt it in the amounts required, this is effectively rewriting something as complex as Qt. ^.^;
Huh? Since when does kWin work on windows? Windows, even Windows 10, doesn’t even support half of what plasma support.
Huh? What would this renderTabs function do? How would you want them rendered? What should they display? What listens to the events? What information should they show? Etc… etc… Tabbed interfaces are not trivial things regardless of where they are (though if you want them at the top then just render them at the top with the titlebar flag disabled, although some window managers will still override you and put a titlebar as they don’t support titlebar-less modes).
Themes havn’t been “Just Colors” in over a decade now. Now they are more like a texture + shaders on everything from Windows 10 to Plasma and more, and limiting yourself to just colors means that your application won’t fit in with the rest of the system.
Cursor style? It uses my defined OS cursors here. Unsure of what is being referenced?
Older Firefox very much did not mesh with the OS, I like it quite a lot more now. In older versions the chrome was rendered via the DOM as well (hence why it was so configureable), but it lost so many features in doing so and was so slow that replacing it with system-native calls fixed both issues. If someone wants to theme it now then they can use their normal OS constructs.
Which is exactly why you should use the normal OS constructs, that is the least painful way to do UI rendering.
That’s because Windows is not capable of plasma’s behaviours. 
Plasma’s interfaces and themeing is a full scripting system, it can quite literally do anything in regards to rendering and input handling. If the user wants a clock on all their titlebar’s, that’s trivial. If the user wants windows rendered as circles, that’s also doable though a bit more work. Handling all these cases on the application side is an impossible task.
Huh? I’m not getting a reference about a shadow? I’m not sure what Qt has to do with shadows? Generally shadows on things are handled by the OS’s UI drawing interfaces.
If you want to manually render a trivial box shadow of a button then you are free to do that yourself, but it is unlikely to look like how the rest of the OS does it, especially if there is a glowing star on a cursor (wife’s computer) that changes the direction and length and color of the shadows based on their position to the cursor. That is not something you can just ‘read from a config file’.
0
Eiji
ok, that’s really good point! Yeah, I know about kanji, katakana and romanji cases. I should remember that.
For sure I did not say to not call anything from system. I would just o limit drawing (components) to scrape and draw.
Yup, that’s definitely lots of data to scrape, but … how to say that … it does not scary me.
That should be scraped - basically everything related to theme itself.
wow, wow, wow
We have big misunderstanding here. First of all I’m talking about app themes which includes only part of window manager themes (titlebar + window related actions like shortcuts <Alt> + mouse etc).
Let’s give a simpler example. Moving window with <Alt> + left mouse to top-right corner would act like <alt>+<tab>. Let’s split it on some parts:
- Catching combination (
<alt>+ left mouse) - Catching mouse move events
- Moving window based on event from 2nd point
- Catching moving window to corner
- Call based on even from 4th point
What I want to handle is: 1, 2 and 4.
What I want to call is: 3 and 5.
Look that I want to solve things which are generic (like moving window) and let window manger handle rest by resending catched events. Let’s say that some OS would not support call from 5th point. We could check support for that based on scraped information and do any of:
- add info to log file
- display system notification
- display warning/error window
What I want to scrape is all window manager keyboards and its actions. When scraped I’m going to manage events on myself and resend them to window manager if specified action is supported or not.
Here really helpful would be to add NIF for example for dbus calls as it would be a really powerful for some tools like implementing KDE shortcuts. What such tool would need is to:
- read global shortcuts
- lookup for binaries from
$PATH - lookup for
dbuscalls - assign, change and unassign shortcuts
- GUI library
Except 4th point everything would be available from helper library and such tool is going to be trivially implemented.
Again what I want to is to handle:
- Drawing
- Events
- Scraping
Nothing more. I don’t want to reimplement full window manager (only events and scraping parts). Sorry if I did not say it enough clearly. 
Well … service help thinks different. Without special tools for cleaning and lookup into registry it would be extremely painful to find autostart entries (from memory - especially if you have more tasks in mind).
Maybe there were good ideas, but same goes to NTFS - it was good … lots of years ago. For sure same goes to X server on Linux, but unlike Windows it’s replaceable - it’s just a matter of time. Honestly I would like to see any distribution now on Wayland …
Well … I prefer to let Raspberry PI do things for what is designed too. I’m not one of those people which runs Minecraft on it.
As said OpenGL (i.e. custom rendering) in some cases (like custom titlebar and drawing separate tab bar on it) requires lots of drawing work (especially when you think about animations).
Please don’t joke about backwards compatibility - I still can’t stop laugh after previous jokes.
I would give just one example:
I had GTA San Andreas with one big modification and here is how backwards compatibility worked for it:
- Windows XP - designed for it, so it worked
- Windows 7 - problems with rendering, black screen etc.
- Gentoo Linux with wine - it works better than on
Windows XP- it had even morefps. I can say that without any tool as I have problem with eyes and lots of small thing could hurt me a lot.
I would not even talk about smaller game which returns error, because of broken backwards compatibility related to network. Basically backwards compatibility works when you install Windows XP Mode or Windows XP on virtual machine. Notice that I have talked about one of most popular game series GTA. Did you know about awesome part of backwards compatibility which forced change naming of Windows from 9 to 10?
I need to agree. While Qt did not give me enough components and was bad at some points (as you said license) it was still pretty nice designed.
For sure: I need to draw custom tab bar component on custom title bar component. I can do it in Qt or in scenic. At end I need to draw component, so Qt does not give me any benefit at least in that point. Again I can agree that Qt works really nice and it was probably easiest GUI library to learn.
Yup, unlike Qt library GTK+ allows to add custom component to titlebar, but unfortunately I can’t make it simple work with GtkNotebook, so again I would be forced to draw me own component. Tabs in titlebar saves lots of space on monitor and I saw lots of people which was trying to do it on their self manually.
EXACTLY
Everything you said is correct. It’s why I want to add library which would also design window with advanced GUI preferences which would optionally disable custom titlebar drawing. Exactly just like in Chrome or Firefox as you said. They have really good integration with OS (moving window to corner etc. That’s what I want to do.
ok, now you really surpised me!
I did not know that’s even possible! I though it’s not possible to touch titltebar in Qt and you wrote even some scripts, nice! For sure I want only those things which could be scraped. I don’t want to execute custom scripts (maybe later optionally Qt library could do that for me, but definitely I don’t want to do such staff).
Oh, you mean this one:
https://hexdocs.pm/distillery/Mix.Tasks.Release.html#module-executables
I really missed that - I just can’t believe. 
I need to investigate. Hope it does not give too much access (after self-extracting) for end-user as I saw in releases lots of debug options.
I would not go so deeper … I … I promise!
Exactly. It’s why I want to draw custom titlebar in order to (just for example) reorder buttons as Plasma allows that. I don’t want to rewrite window manager from Windows.
Right and I would need to draw everything including animations (reordering tabs etc). I don’t want to leave every developer doing that for herself/himself. If I remember correctly Qt allows to split it on QTabBar and … QContainer(?) - something like that. I would like to have something like that in GTK+ which allows to replace titlebar label with custom widget.
Yeah, that’s right. I just said it in short. Of course textures would be scraped in same way.
I have black (probably X server default if I remember correctly).
No, no, no - a bit too much. Again I prefer to not touch scripting or at least call them if current environment supports that.
We have some misunderstanding. You talked about special cases which are possible to only one specified window manager and which are hard to reimplement. From this I though that every part I described looks really hard to implement for you, but you talked about edge cases like scripting.
I’m not sure - depends on implementation. Maybe this tool allows to read color and mix it with its own. I don’t know, but yeah such cases are definitely too more to handle manually.
Basically I want to implement mainly GtkHeaderBar + QTabBar (hope I remember name properly) + allow to change theme from other GUI libraries (not only GTK+ themes). Things like reorder titlebar buttons or move titlebar to different edge etc. Rest should take window manager assuming if it’s not conflicting with custom titlebar.
0
OvermindDL1
Well that’s the thing, the OS theme effects the rendering of the widgets/components within programs as well, and it is horribly obvious when a program does some manual rendering of, say, even a button because then it looks horribly out of place.
Even moving a window is not generic though. The growing standard display on linux is now Wayland, Wayland does not have a concept of a simple 2d drawing screen. There are even wayland plugins that render programs as floating windows in a 3d landscape that you walk around in either via an FPS style controls on screen or via a VR setup. Not letting the window manager control these things will absolutely break in quite a number of times.
How do you scrape all such things though? A lot of then are not just simple hotkey mappings and so forth but are entire running scripts that dynamically respond to various changing conditions.
That would only read static global shortcuts. On my computer I have a huge number of dynamic shortcuts via scripts (simple bash scripts) that do different things at different times with different commands.
What for? And that wouldn’t catch direct calls either.
DBUS is introspectable and self-documenting (mostly), you can just introspect into it.
Heh, a user program definitely doesn’t have access to do that except within their own scope.
This is still the hardest part overall, it’s about impossible to render things the way the native system does without just letting the native sytem itself do the rendering, there is quite literally an infinite amount of things to consider otherwise.
And if those are dynamic based on non-static conditions?
This means writing full language interpreters for so many different formats while handling native binaries, javascript, and python at the very very least, just for KDE alone, on Windows there is a great deal, etc… etc…
Huh? Autostart entries are on a specific path, very easy to access, although windows has quite a variety of non-registry based autostart areas as well.
Quite a number are on Wayland now with a fallback to X if your GPU doesn’t support 3d-accel. Wayland is even default for most KDE distributions I’ve seen lately.
About every modern OS out already renders windows on a 3d context (which you are technically doubling up on with scenic, scenic renders to a context it creates, which draws to the OS context, which draws to the screen, with a native app you can skip that indirection on many systems, including windows). Even on windows you can get access to a windows framebuffer directly (which skips the windows managed chrome of course).
I’m extremely certain GTA San Andreas renders in OpenGL/DX, thus it doesn’t use the native UI calls at all, thus backwards compat is unrelated here.
Backwards compat with it having issues rendering is likely either it not following the OGL/DX spec properly or broken drivers, neither of which are Windows fault. Windows itself, much as I don’t really like most of it, is fantastic with most of its backwards compatibility (now if only that extended to the rest of Microsoft).
That is because a LOT of exceptionally poorly made programs tested the windows version by grabbing the string and seeing if it starts with “Windows 9*” instead of using the actual interfaces for testing the windows version number. Again, Windows did the right thing here, a lot of programmers didn’t.
QT doesn’t give any benefit? Other than that it has already abstracted the OS UI native calls or that it gives you an OGL context that you can draw into or that you can override the drawing and theme anything differently or that you could just put a tab bar at the top and init the window with the NO_TITLEBAR flag or anything of the huge amount of other things? What does scenic gain over it?
Yeah it does that by just turning off the titlebar management, like you can do in Qt or wxWidgets or whatever else.
In general tabs on a titlebar doesn’t save space unless an app already has tabs. For me it doesn’t save space even in programs ‘with’ tabs like chrome/firefox/whatever as I still have a tab bar above that for combining multiple different programs into a single window. In addition you, say in windows or whatever, still have the taskbar on whatever edge of the screen you want that is already a set of ‘tab-like’ things that can merge windows of a program or not optionally among other things that the user can already position as they want.
No clue what you are referencing here either, they don’t do anything of the sort, my window manager does, and I know its my window manager doing it because I get the 3D window manager effect of it when it snaps, which is absolutely not something that the program itself can do at 60fps.
Then call into the native interfaces, without it the interfaces will be broken for many user functions.
Except plasma doesn’t just reorder. Even right now my Close button is a dark X in a gray circle that fades in to red when I hover over it over about 150ms while the X changes shape to be more bold over that same 150ms, or the maximize button is kind of a big up caret looking thing that fades in to blue when hovered and when clicked the window scales with a slight quick bounce to full screen while the maximize button kind of ‘folds’ down into 2 carets that then attach at their ends forming a diamond, etc… for all the rest of the buttons as well (minimize, shading, pinning, etc…). These are controlled and managed by compiled ‘scripts’, it’s not a little file that you can just scrape. How would you manage to replicate this without calling the native interfaces?
Leave that to the native interfaces then, they shouldn’t have to implement that. That is what things like the KDE Framework are for (KDE Framework is an extra set of components and utilities on top of Qt, since KDE is built on Qt, and KDE Framework programs can be compiled for anything from windows to mac to iPhones/Android to much more).
How would that happen? If such a texture does not exist as a file on the filesystem but is another framebuffer entirely with its own dynamic content, how would you do that?
That sounds horrifying… ^.^;
Yeah the big/giant black X with the white outline is the default X cursor, that also means you are using X and not Wayland. ^.^;
Then can’t get the theme information from the window manager then.
Static Shadows are super easy, dynamic shadows require more information. I even had shadows on Windows XP ~18 years ago where the shadows shone ‘away’ from the mouse cursor like my wife’s computer does right now (not light on the CPU back then, ^.^;).
But what color? Like how would you render a shadow in your program if the window manager itself projects a shadow from the cursor that takes the coloring of the widgets/components that the light interacts with.
0