How about crowdfunding for scenic-based libraries/projects?

@massimo I 100% agree with this image. However the world is not written in just one rule. There are always lots of edge cases and I believe we are already in such situation.

First of all we have 2 good UI libraries in Erlang/Elixir I know (:wx and scenic). We already quoted why scenic is better. In first place I would like to extend scenic and do fork only if @boydm would say something like:

I see what you want to do, but it’s not how scenic would be developed.

With is 2nd type of edge case for this image.

Secondly “standards” here are themes. I don’t want to write one more standard for them (like different config file with different properties). Instead I want to allow scenic (actually developed standard - not new one) look like other standards. Please notice that I do not want to add feature like:

new standard keyboard shorcut for scenic-based apps

I just want to read how other standards are configured and make existing (again scenic) standard use them.

This means that instead: ~/.local/share/scenic/themes/theme-name I want to have ~/.my_app/ui_config with example content:

[UI]
Local=true
Name=oxygen-gtk
Path=/path/to/theme
Type=gtk3

# or
[UI]
Local=false
Name=oxygen-gtk
Path=(ftp|http|https)://domain.name:port/path
Type=gtk3

Yup, but not all works as good as scenic in Elixir, so other libraries does not matters for us.

I don’t want to. I’m Elixir developer and I don’t have any benefit with exporting library API to any other language. The only discussion here could be support for other BEAM languages. I just want to write well configurable apps in Elixir - I was never talking about other languages. I tried to do similar things (like custom titlebar) in other languages and GUI libraries.

Great, another standard to scrape theme :smiley:
It’s written in C++, so it’s not what I’m looking for. Again I would like to extend scenic library.

On embedded devices there is only matter of themes and components. Look that desktop app have usually more features like global shortcuts. I don’t see full desktop-like GUI with mouse support on small displays, but most probably somebody already made it. :smiley:

Yeah, I’m thinking about it too as part of this topic.

Definitely, it’s one of components I would personally require for apps I want to write.

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.

2 Likes

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. :slight_smile:

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. :slight_smile:

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. :smiley:

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:
https://hexdocs.pm/scenic/Scenic.Component.Button.html#module-theme

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.

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.

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 :icon_question: for what I’m planning.

In short there are 4 biggest parts of my plans:

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

  2. OpenGL part - it should not be a problem for someone experienced in this topic
    Also again I did not had a chance to do anything bigger in OpenGL, so for me it looks hard.

  3. Reproduce window manager behaviours
    This could be even skipped on compile time for nerves devices.

  4. Introduce other API - not strictly related to scenic like system notifications, system sounds etc.

For me biggest priority are in order:

  1. Research and OpenGL work based on results
    In order to have everything prepared even if there is no scrapers for any theme files.

  2. Make scenic (or its fork) work properly from CLI for end-user (instead of distillery releases).

  3. Add support for OS notifications, simple (icon + menu) tray icon etc.
    Later maybe even Plasma 5 custom tray support.

  4. Add more components

  5. Add i18n support

  6. Add scenic libraries for themes and related

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

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.

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. :smiley:

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. :077:

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. :slight_smile:

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 (:exclamation:) 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. :077: 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. :smiley: For now my salary is only 20 USD / hour.

Yup, now:

  1. Can I use all behaviours of kwin in Windows XP build of Vivaldi?

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

  3. Themes there are really, really limited to few colors. After adding more components (without extra styles) then scenic would be more configurable.

  4. At least for me Vivaldi uses 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.

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. :slight_smile:

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. :wink:
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’.

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. :smiley:

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:

  1. Catching combination (<alt> + left mouse)
  2. Catching mouse move events
  3. Moving window based on event from 2nd point
  4. Catching moving window to corner
  5. 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:

  1. add info to log file
  2. display system notification
  3. 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:

  1. read global shortcuts
  2. lookup for binaries from $PATH
  3. lookup for dbus calls
  4. assign, change and unassign shortcuts
  5. 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:

  1. Drawing
  2. Events
  3. 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. :frowning:

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. :smiley:

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. :077:
I would give just one example:
I had GTA San Andreas with one big modification and here is how backwards compatibility worked for it:

  1. Windows XP - designed for it, so it worked
  2. Windows 7 - problems with rendering, black screen etc.
  3. Gentoo Linux with wine - it works better than on Windows XP - it had even more fps. I can say that without any tool as I have problem with eyes and lots of small thing could hurt me a lot. :smiley:

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? :smiley:

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. :confused: 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! :077:

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.

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. :slight_smile:

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. :wink:
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. :wink:

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.

Yup, but you made a small mistake. As we are talking about KDE/Plasma, Gnome, Windows XP etc. we are not talking directly about X window system and therefore also not about Wayland. I’m sure that there are such 3D interfaces (always want to try this one which looks like a game), but … “I would talk” with kwin_wayland instead of waylnad libraries directly. I know that window manager topic is big, but I really don’t want to follow hardest way - I want to do as much as possible for things that are worth. Even if there is no CSS parser library it could be useful for other.

For this I need research. I know that Plasma have lots of easy to scrape config files. If something is not possible in specified OS then I would handle {:error, :not_supported} or something like that. Well … if you are using Plasma everyday you could quickly forgot that other window managers are not so awesome. :smiley:

Sorry, I don’t get what (shell?) commands have to GUI apps and their shortcuts. Of course I would support global as default with option to override them. For example I could let you select oxygen theme and choose icons from other theme or even change a single color. All would be handled by settings viewport defined in library and final app would need only to save settings on its own and read them when initializing viewport.

Yup, I know! I don’t remember, but there was even an app for list all DBus applications and it’s calls. For example I could show and hide yakuake and added it to Plasma config file to call it on pressing <Super> key. That’s really good way. :smiley:

Well there is an Plasma app so it’s possible. :smiley: Anyway as you said app could store its shortcuts as in its own scope. I would even want to store my own as DBus calls. That would be definitely awesome!

For sure in details everything is bigger. Generally I want to take all supported event types and try to scrape each checking if it’s supported.

For sure I’m not expert, but in Linux I saw everything easy to find (like config files, icons etc.). Comparing to Windows where icons can be in dll files (if I remember correctly) it looks much easier.

I don’t want to write any interpreter. At very least I would use current OS interpreters to handling special cases in future. For now I’m interested only in generic things. I don’t want to reproduce something which conflicts or overcomplicates whole implementation.

Again I want to draw everything which looks like themes. It does not need to be exactly equal if it’s really so hard. Just look at Plasma settings window. What it allows to configure/change. I just want to for example expand color scheme from Plasma settings, so app (and its dependencies) could draw components based on them. Of course there goes more than colors - I’m just giving colors to now write everything. :slight_smile:

Yeah and require from everyone to remember them or implement app with proper autostart support for every case. It’s definitely overcomplicated, hard to remember and use. It’s just like comparing Firefox config page and Chrome flags page. For sure Chrome have less options, but it’s mainly because of project assumptions and descriptions for flags.

Default does not mean that everything is ok:

Wayland Support in Plasma

Wayland support in the KDE Plasma Workspaces is in a tech-preview state. The workspaces have been developed for X11 and much functionality relies on X11. To be able to make proper use of Wayland these bits have to be rewritten.

The most complex task is to implement Wayland support in KWin, KDE Plasma’s Compositor and Window Manager. Since 5.4 KWin is able to manage Wayland clients and this allows to start a Plasma session on Wayland.
(…)
This page was last modified on 13 January 2019, at 22:08. Content is available under Creative Commons License SA 4.0 unless otherwise noted.

Source: KWin/Wayland - KDE Community Wiki

Oh, I could remember it wrong. I though that version checking happens in OS library.

Yeah, but that means again drawing and handling custom window borders, movable part of QTabBar, window controls (minimize, maximize, close) etc. Nothing changes here (unlike in GTK+ when you simply had GtkHeaderBar). I would need to fetch anyway lots of information as you noted about writing custom titlebar. I just said that if we have here and here same thing (scrape, draw and handle) then there is no benefit with using one over another in this specified part (not at all). Qt have some native calls, but it’s definitely not best for Elixir as scenic is better option than :wx.

Writing huge NIF for full Qt support or writing drawing part in scenic - in both cases it’s a lot of work, but I could be wrong … btw. is it not possible to have “something in middle” like scenic which uses native calls like Qt?

Yup, the difference here is that you do not need to write so much code. I would like to see so simple solution in scenic as well.

Even if you have extra tabs above then instead of: 1 vs 2 you have 2 vs 3 bars. At any case Firefox part reduces in 33% or 50% (depends how many bars you have).

Yup, most probably handling it is too more. When I started thinking about it firstly I though more about app window and not everything around it. I probably go too far with this part. It’s just because I’m used to have everything so easily configurable in Plasma which is just “waiting for me”. :slight_smile:

ok, so we have collision here

  1. Go with native interfaces
  2. Go with something like NO_TITLEBAR flag in Qt
    Or maybe it could be combined? Sorry I could get lost here.

ok, I see … so it’s just not possible to apply theme from other OS / window manager, because instead of button states (or animated images) we have scripts everywhere, right? It looks like overcomplicated for me. Is that because everything is on old X server?
Maybe I’m wrong, but personally if I would design such button I would think about animated SVG file which is simply generated based on colors (again and more) from theme file. I’m not sure why there are so many scripts. I probably assumed too much and I though that it works actually a bit easier.

That would be ok if there would be API like GtkHeaderBar, so I would just do not need to think about other things. Unfortunately I read that it’s considered as a bad practice for KDE developers and therefore they did not implemented that feature.

oh, please no! I saw already scripts with binary content and it looked so weird. Don’t tell me that there is so much staff like that. :frowning:

ok, honestly it’s just terrible
You want to add simple Windows XP theme, but you need tons of weird staff like interpreters. I don’t like how it’s solved. I don’t though that there is so much mess.

I think that you descried well why it’s so hard to scrape all information. For sure I don’t plan to finish with scraping. I would just limit it to not take too much time for it. If something is scripted then I would simply reject it. I would definitely scrape some system colors, textures etc and allow to draw “similar” themes (i.e. allow app to have good color scheme like app background).

As @massimo linked image I would most likely to create my own standard i.e. my custom window icons. As @OvermindDL1 said I would use system calls as much as possible (especially I would like to add DBus support). Maybe later I would add few extra features which are pretty easy to implement (I don’t want to overcomplicate problem and make it working after few years). Honestly I did not planned to do something like that, but I see that I don’t have a big choice. I plan to have buttons in animated SVG format which would be generated based on color scheme (like button background color).

Except those ‘leak’ into the window manager as they have different feature sets, and KDE does change its capabilities depending on the underlying rendering engine (X, Wayland, or Windows for as much as it is supported). And you really don’t want to talk to the wayland libraries directly, those are not designed for ‘program’ use as they are very low level and kind of horrid (and X’s is even worse!). ^.^;

Except none of those define the overall themeing of the system, just general settings and defaults and so forth.

As in when I hit certain ‘shortcuts’ they instead get redirected to a set of scripts that I’ve made over the years that do different things depending on the program that is focused, where the mouse is, the time of day, etc… etc… It would be impossible for a program to emulate that as the keyhook for it happens even well before it hits the GUI at all, and I use a LOT of these scripts, apparently 27 I just ssh’d home and checked.

So… a single program would be themed like oxygen instead of the custom theme I have running on my system? That would be highly irritating, and the dark/bright would be super jarring… o.O

I really quite like DBus too, it’s a bit crufty sure but it is really functional. ^.^

But how would you scrape what binaries do?

Heh, actually this is one area where windows is a lot more simple and easy in. Window’s icons can be in the resource section of PE files (like DLL’s or other executables) and those are super easy to extract. Compare to linux where a given ‘icon’ might be an ico, or a png, or an svg, or a program that outputs and animates it in real-time.

Hence should just use the native calls, let the OS handle all the drawing. ^.^

That settings interface is a super simplified version of the themeing system in KDE. Themes can not only adjust colors but entirely change how things are rendered altogether. Just looking at that settings screen is entirely useless in some themes because they do so much in code (like the one I use).

Though wayland is required for most of the newer features, and the development on the X backend has stopped entirely except for critical security patches. The X backend can’t even accelerate the new systems anymore.

It’s supposed to, programs are supposed to call the proper winapi’s for it, just a lot didn’t and instead just tested a string prefix for whatever stupid reason. >.<

Which doesn’t work here anyway so that’s not a useful example. :wink:

That seems rather useless at that point then. Qt already can give you an OpenGL context with a HUGE host of commands for it (plus you can drop down to the base OGL calls themselves), so wrapping Qt with Scenic is quite useless as Qt already has all the functionality of scenic and a great deal more, so you’d be losing capabilities compared to just using Qt. Using the native calls across OS’s is a rather amazingly difficult task. Look through Qt’s compatibility layers for each system types and how it tests what to use and all, it’s a bit of a horror, just because there is no better way to do it.

In Qt you can put up a window in 1 line of C++ code, and you can have it host a QtQuick2 interface in it with another like 2 lines. Qt is crazy simple compared to any other API I’ve used. Even staying constrained to QtQuick2 and a binding layer to define your own components for it a Qt interface for elixir would be incredibly powerful, and that’s all before you get into any of the bigger things. Though I’d do it as a Port instead of a Nif.

Exactly, I hate programs having toolbars up top. :wink:

That’s still a native interface, just letting you handle the drawing, you can even pass the messages back up, and the user can still override you to force a titlebar anyway (as I do system-wide).

Nah, X doesn’t have anything to do with this, rather it’s just the theme engines built up. Windows has some replacement theme engines (windowblinds was a popular one, unsure if it still exists) that are pure machine code in their capabilities, KDE’s theming system is actually built on a combination of QtQuick and additional scripting language interactions, etc…

How would you animate it? Would you use javascript? So you’d need a javascript interpreter then.

That’s how they work, like KDE Plasma builds in Javascript (V8 I think), Python, and binary file execution for it, and more can be added by other plugins. It is for maximum configureability by the user as it is the Users computer, not an applications computer.

I looked up this GtkHeaderBar, it appears to specifically be designed for tool child windows and/or simple popups, it is not for tabbed interfaces of any sort nor was it designed to mimic being native at all (it specifically appears that it is designed to not be native looking, which that would bug the heck out of me…).

Lol! Actually that’s how both Plasma5 and Windows 10 both work, they both have full support for framebuffers as textures, that is how Windows 7+ does the transparent blurry moving clouds animation in the chrome for example. ^.^

GUI ecosystems are the very definition of “A Mess”, they always have been, and they only get so so much worse as time goes on. Trying to mimic them is not a possible task anymore, even wxWidgets tried that a long time ago before it finally gave it to just making the native controls be the defaults in 2.7 or whatever it was (the last one before 3.0).

So on many modern systems you’d get no information then. ^.^;

What kind of animated SVG though, javascript? Something else? How would you have it able to support dynamic interactions?

Honestly I’d say if a desktop app is wanted and wxWidgets is too…low level and crashy for your use, then elixir could use a really good Qt or KDEF wrapper library as a Port… ^.^

Well … I definitely prefer to have oxygen theme rather than “this” what Windows 10 offers. It hurts my eyes way too much. I can’t work with this half dark and half white apps. Unfortunately KDE apps are in tech-preview version now.

Wait, why it’s not working? I have it working every time even in Plasma.

Why you want to put everywhere JavaScript? Like it’s a solution for everything … I don’t get why rendering animated image requires other language.

So it’s impossible to write configurable software in Elixir? Is rendering of images so hard that it’s easier to require few extra language interpreters?

ok, hello from another universe :smiley:
When nautilus has been changed to popup window?

Lots of GTK+ based apps are using it …

Also just take a look at this image. Just animation for change order of buttons and + button for new “tab” button. I don’t see why it’s bad to think that tabbar would not look good there.

Finally I’m completely lost what do you call native look. GtkHeaderBar is just using GTK+ themes and its drawn by GTK+ engine, right? Nautilus is great example of what I would like to have - I would only add Plasma like settings window (of course related to how app is looking) to change theme. It’s all I would like to have.

I see …

I prefer to create my own standard then and work like scenic is working already. I would just add an option to make app more look like native by scraping for example color schemes which should not be a big problem.

If you said that GUI libraries are overcomplicated then best way is to write new one. I really don’t want to fight with 4+ languages (Elixir, C/C++, JavaScript and Python as you said) to create one button. Way easier is to write everything from scratch on our own configurable, but simple rules - without a magic. It’s like I’m not saying that Qt is bad as same as Rails, but magic is magic and I don’t want to fight with overcomplicated solutions.

It could create extra costs, but at least we would have more job offers and it would be done right without overcomplicating so simple things.

If you ask how others could scrape my themes then answer is simple. At start of course it would not be a priority, but later I could consider exporting theme. For example I could save *.bert files (in binary erlang term format). I don’t remember much of animated SVG, but we could simply return our animated SVG template which could be themed and rendered as other wish.

Lol, is it still that bad on Win10? ^.^;

I force titlebars on all primary windows, otherwise I can’t get my application-tabs working. ^.^

Speaking of, you can actually tell KDE that you will work with its tabs directly and then it will just cleanly integrate them all. A few browsers here (not firefox/chrome) do that. :slight_smile:

SVG’s are not an animated format, and javascript is the most common method of animating them by far other than simple CSS transforms (which also requires a CSS rendering engine then too). SMIL is the closest that you’d get but its extremely limited.

apng or so would be better in general, but those aren’t in heavy (or barely light) use. :frowning:

You have to parse the information ‘somehow’ if you want wanting to grab the pre-existing theme information for a users desktop, and if their theme is in, say, javascript, well that’s what you need to run then.

That’s not a nautilus thing, that’s an ubuntu thing, I’m not even remotely a fan of its interface. ^.^;

I don’t think that’s the apps themselves, rather that’s the theme of the window manager being used, specifically Ubuntu’s (I’ve seen that exact one on Ubuntu’s anyway).

Well GTK is not native on my system. GTK apps look very poor and quite frankly I abhore them (I don’t even think I use any anymore…). So no, GTK is not even remotely native here. ^.^

I think there’s a related XKCD comic about this. ^.^

Heh, but still, that is what wxWidgets was for, and then Qt was for, and there’s been others and those are the only two ‘mostly’ successful ones, Qt far more so than wxWidgets.

Oh it could potentially be a LOT more than that, that’s just a baseline example.

That seems like significantly the harder path overall. The easy path would be to just use the native calls themselves for the given winow manager.

Qt is quite the opposite of magic, it is dreadfully direct, far too much so in many cases (though necessary because of underlying GUI system differences). The only thing that’s hard to trace at times is it’s pubsub (signals/slots) system because you can link anything to anything (though that’s pretty common in GUI systems).

I never get why people are grouping different apps. I like tabs in Dolphin, but I never feel a need to mix multiple apps. :slight_smile:

Are you 100% sure? Look at this one:

https://upload.wikimedia.org/wikipedia/commons/b/b9/SVG_animation_using_SMIL.svg

You probably never read about SMIL:

It’s 100% XML to parse and draw. Exactly 0 CSS and JavaScript code.

I said that I don’t want to go so deep. If there are config files or maybe libraries which returns raw values (like: [255, 255, 255]) then I could consider using them. I know that at least Plasma have lots of configuration written pretty easy. Generally lots of (most? or even all?) Plasma configuration (I mean settings which is enough for me) is written in config files and DBus calls (to control apps). Including even CSS parsing from GTK+ themes is everything I would like to. I definitely don’t want to touch script except markup languages like XML (for example: SVG images).

Lol, no - as far as I know Nautilus is using GtkHeaderBar. Ubuntu have something to read menus from apps and add them to system bar, but I’m talking now only about custom titlebar.

You really did not get it. It’s not about Ubuntu - it’s in GTK+ documentation:

You can put any class instance which extends GtkWidget (if I remember correctly how it worked). I mean that you can put there any widget from GTK+ documentaion that you want. Maybe there is even way to draw your own widgets. I have used it lots of years ago, but remember how big potential it had. As said I just wanted to see there tabbar from GtkNotebook + some ways to personalize it a bit more (changing theme, order of buttons etc).

It’s native, because it’s written in GTK+ engine. I don’t get how much more you require for having native look. It’s one of standard GTK+ theme. Of course unless you would set special theme (like oxygen-gtk) then GTK+ apps would not look like Qt apps, but same goes in 2nd way too.

yup, that’s right

Don’t scary me, please. It’s why I don’t want to touch it at all. Better is to work on your own drawer without weird scripts in 50 languages and limitations which have no sense.

Yeah, and handle all of that edge-cases, 50 languages etc. I’m sure window manager would get it, but after that I would not have more options to personalize than on Windows, so sorry it’s not for me. :smiley:

Any overcomplicating is magic in my dictionary. :077:

I can’t accept anything with some much complicated structure. I don’t want to compile not only Qt, but also few languages just for settings window with support for multiple themes. Of course I understand that I don’t need JavaScript for every basic component, but look that I’m not typical Chrome user I want to have more and more. :smiley: For Elixir developers it would be easier to stick with OpenGL and Elixir instead of as you said so many languages.

I like configurable things, but not when their are overcomplicated. I’m not satisfied if any of my work is not enough configurable or it’s too complicated. Even if it requires to rewrite something I want to make everything as easy as possible. For sure as said I will not rewrite window manager behaviour, because as you described it’s also too complicated. I don’t believe that Elixir would be good to write window manager from scratch, but who knows … maybe something in future … :077:

Summary:

  1. After discussion/research I would design and place some job offers for new UI library (without requirement to GTK+ or Qt).

  2. scenic is designed for nerves devices, so most probably I would need to create its fork for desktop apps

  3. I would write some helpful libraries (with NIFs) to support other desktop features like system notifications and tray icon.

  4. Unfortunately window managers are overcomplicated, so I’m not going to reproduce their behaviour for all OS - I would just call supported by current window manager features.

  5. I can imagine writing few extra behaviours which are easy to implement like <Alt> + mouse should be as events would go to our window (i.e. I would not simulate window manager events with transparent window or other hacks).

No one else I know uses them either but I quite like them. It sucks that a theme has to be built with them in mind or they don’t work, that’s actually the big reason I use a custom theme. ^.^;

Yeah that’s SMIL as referenced in my post, not just SVG. It only works with prebaked animations using a set of commands to manipulate the nodes. Last I recall (it’s been a while though) it was not capable to create/remove SVG nodes so you could only manipulate.

So yeah, wouldn’t be able to parse the theme I use then for example. A button doesn’t have just a single color as one of many examples, rather it’s a gradient that reacts to the mouse position (not just hover state but precise position) and more.

Ubuntu by default removes the titlebar of supported applications to make a combined menubar/titlebar/more thing instead. I’ve found it makes it hard to click on things without accidentally clicking on something that’s active.

Ubuntu ‘uses’ GTK as it’s rendering engine, like how KDE uses Qt as its rendering engine. Putting things at the top of the window with a hidden titlebar is not a hard thing to do, and that’s what that widget wraps. Not a hard thing but definitely not very fitting into other interfaces. :slight_smile:

Native to Ubuntu sure, but not native to a different system like Qt or Motif or Windows or so.

Precisely! It won’t mesh with other rendering systems. :slight_smile:
Where if the native calls are used then it does.

Heh, different distributions and OS’s do lots and lots of different things. ^.^;

On windows yep, but using the native calls on each respective system gets it native looking regardless, native being “Like the rest of the applications”. :slight_smile:

Qt makes it simple and clear then, if a bit wordy at times, it is soooo blissful compared to older styles, and that includes wxWidgets (which is very Win32’ish in its API on all systems, blegh).

I don’t think Elixir is actually capable enough to act as a theme backend actually, hmm… could be an interesting test… The issue is it has to respond fast, like way blazing fast to render commands.

Just don’t expect it to fit into the usual desktop systems is the big thing. ^.^;
Which is perfectly fine for things like games, which have a very game-specific UI anyway.

And what would that do on systems where the user expects alt+mouse to do something entirely different?

Simply checks if it’s reserved already :slight_smile:

Hmm, how would it do that? I’m not sure I can think of a way to check my bindings on my system as that’s kernel level interfaces (it’s handled by the keyboard driver that gives updates out to a privileged listening program) without higher level access that I definitely wouldn’t want to give a usermode program (since then it could listen it to all my input system-wide).

There are lots of apps which manages local and global shortcuts. I don’t think it’s so much hard. I would just need to take a look at some open source projects …

For sure I don’t want to do anything new. I just want to create from scratch something based on what I have seen already and was not enough configurable for me. It’s not like that I suddenly decide let’s get that no matter which way, but I just saw that specified thing is used by some apps already.