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.
stefanchrobot
Eiji
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 GTK+ and 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 SVG with 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.
3
stefanchrobot
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.
Maybe Scenic would make good use of something like XAML in WPF or JSX in React.
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.
1
Eiji
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 SVG + SMIL as XML-based standards are really simple and don’t require huge dependencies (like compilers for other languages).
If I remember correctly both Angular and React were frameworks. As we have “framework” phoenix which is basically more library than 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 phoenix).
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 my_app_web.
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 SVG+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:
[1]
Icon=/path/to/icon.svg
OnClick=dbus.call.goes.here
Type=Button
[2]
Type=AppTitleComponent
# or TitleBarOfAppTitle in case of grouping windows in tabs
# requires: >=plasma-addons/special-component-x.y.z
[3]
Type=SpecialCompnent # simply skipped if not exists
[4]
Icon=/path/to/icon.svg
OnClick=dbus.call.goes.here
Type=Button
[5]
Icon=/path/to/icon.svg
OnClick=dbus.call.goes.here
Type=Button
[6]
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.
0