Only in specific contexts, like looking at local/global shortcuts managed by a specific interface, like kwin for example, but they don’t see ones of the contexts that they don’t know about.
Seems like there’s no way to talk @Eiji out of this. I think the best course of action would be for you to verify how many people would find the tool that you’re building useful. Obviously - like me - you can just ignore that question and do it just for fun, but that’s a different story.
That’s not 100% true. Just my brain thinks in much different way than others (it’s not a bug it’s feature). I’m trying to understand your positions. I’m even asking questions to better understand what other said and I’m changing my plans, because I have not so much knowledge at this point. It’s why I just give up with some of features as I see that
Qt look and feel is not so easy to reproduce.
Basically others and me comes from different assumptions. For me the most important is to not create/use too much overcomplicated solutions. It’s why instead of
GTK+/Qt with scripting API for “50+” languages I prefer to introduce simple
SIML animations. Those 2 are well known and easy to understand. Most of people would get what’s going just to read “few words” about them (if they don’t know them yet) and looking at their source. Basically everyone who worked with
XML before would not have any problem with understand them unlike custom scripts in languages which you could know only their name.
I totally got why using
Qt is good solution. I have worked with it in
C++, but after some time I just tried other library and later other language. It was best
GUI library which I know in
C/C++ world, but I did not really loved it. I decided to use
Elixir not because everyone knows and use it - I just found that it’s perfect language for my use cases. I don’t even though that here could be created such
GUI library. From first time when I heard about
scenic I just wanted to take a look at its source unlike in any other
GUI language I have worked before. I have even started to believe in
love at first sight!
I’m not sure how many people would use my fork, but I really don’t care about it. In other situation it would be a big priority for me, but here as long as it would be well written I would use it for really lots of desktop
GUI apps which for now are too complicated to create just because scenic offers only basic features now.
I did not found in your reply, so I don’t even know what should I ignore. I will definitely do it for fun since it’s not something “just for work”, but also it would be really important dependency for my future projects.
Sorry if I came out sounding condescending, that was never my intention. I truly applaud all innovations and thinking out of the box and you seem to be doing just that.
Really, just one thing that I’m concerned about - basically because I did that myself - is overlooking the fact that some things can be labeled as “just a matter of X”. What I mean by that is that it’s sometimes easy to heavily underestimate the effort required to get some specific thing to a “ready” stage. Let me give you an example: I honestly think that React is better than Angular. AFAIK still to this day, there are no official React components (think of something like Boostrap; I acknowledge the fact that it won’t happen), whereas Angular comes with a set of Material components. That was really the thing that let my team deliver a pretty involved SPA in Angular in reasonable time, whereas whenever I start with React I need to research what components are there so that the app looks decent. So one could say that for React “it’s just a matter of writing the components”, but still… they are not there.
Makes total sense. I’m just thinking if this can get enough traction. After reading through Major Linux Problems on the Desktop I’m starting to think that investing into Linux desktop apps is a waste of time. Pairing that with the uncertainty of where Windows apps want to go (Metro or not?), the need for cross-platform GUIs is somewhat fading.
Not really - as said I have typically other priorities. I like how advanced is
Qt, but I don’t like that it’s so hard to reproduce it’s look and feel. For me in this case matters all or nothing. I want to have something which would be configurable, powerful and easy to understand for every newbie, so special script in other language just to animate one button is definitely going to be rejected. It’s why I’m thinking about
XML-based standards are really simple and don’t require huge dependencies (like compilers for other languages).
If I remember correctly both
frameworks. As we have “framework”
phoenix which is basically more
framework I’m not a fun of any
framework, so for me both are too bad, because for newbie
framework and its “magic” is really confusing for newbies (unlike in mentioned
I’m sure that what I have in mind is lots of work, but as long as its best solution (again for me) I will look for a ways to introduce it.
Last time I got similar idea. I though about
my_app_scenic which would look really similar to
Yeah and in my opinion it’s just because of overcomplicating problems. Look that everything (system-wide) could be basically written using configuration files and
DBus calls + as said
SMIL - there is no sense for me to dynamically add more buttons for windows using other languages. For sure such weird ideas were introduced just because some specialists follow
Chrome-like way which limits
GUI to minimal, because typical user is stupid for them. For me it’s just excuse to not pay for extra work - keep it simple … to pay. After that people need to think about frameworks and other things.
Instead of I would like to see something like:
# ~/.config/desktop_environment/windows/title_components.cfg:  Icon=/path/to/icon.svg OnClick=dbus.call.goes.here Type=Button  Type=AppTitleComponent # or TitleBarOfAppTitle in case of grouping windows in tabs # requires: >=plasma-addons/special-component-x.y.z  Type=SpecialCompnent # simply skipped if not exists  Icon=/path/to/icon.svg OnClick=dbus.call.goes.here Type=Button  Icon=/path/to/icon.svg OnClick=dbus.call.goes.here Type=Button  Icon=/path/to/icon.svg OnClick=dbus.call.goes.here Type=Button
We have already so much powerful things, but for some reason it’s too hard to make them work so easy.