Crowdsourced GUI. Open beta testing. - page 27

New comment
 
I have to admit that not all of the goals have been realised by the 3rd. The functions of adding and removing windows are not finished. Deleting items does not work. There are bugs. One serious bug I didn't notice yesterday, I'll fix it today and republish it. However, there is already enough functionality to build and connect a simple panel. The whole process takes minutes.
 
I have decided to finish the basic functions and publish them at that time. Tasks are clear: I need parallel editing mode for multiple windows together with adding/removing elements and selective loading of projects.

I will publish the editor after I solve the first problem and start public testing. I can't check everything by myself and I need helpers. Nikolay, Alexey and other participants of the topic, please don't disappear. Together we will make a big step forward.
 
Алексей Барбашин:

It's not going anywhere! The interaction between the two logics still needs to be built. View does not exist by itself. Some of its elements are always binded to variables and/or objects of the application model itself.

You're right on all counts, Alexey. There is only one problem - you don't recognise "the same Fedora, in a different sundress" in terms of objects and approach in general.

The problems of interaction between the two logics are already solved and hidden in the functionality of the plugin engine. The user is given functions to control the elements and doesn't need to look at my code. So, everything is fine.
 
Реter Konow:
You're right on all counts, Alexey. There is only one problem - you do not recognize "the same Fedora in a different sundress" with respect to objects and approach in general.

The problems of interaction between the two logics have already been solved and are hidden in the functionality of the plug-in engine. The user is given element control functions and doesn't need to look at my code. So, everything is fine.

We'll wait and see. So far I see a flagrant substitution of concepts. All programming concepts of the last years have been turned inside out.

But let's wait for the result, let's not cut it in the heat of the moment.

 
Алексей Барбашин:

We shall see. What I see so far is a gross substitution of concepts. All programming concepts of recent years have been turned inside out.

But let's wait for the result, let's not cut it in the heat of the moment.

Well, and if the result justifies the reversal of generally accepted concepts, what then?
 
Реter Konow:
Well, if the result justifies a reversal of accepted concepts, what then?

Strange question. What do you expect?

I'm 100% sure it won't...

 
Алексей Барбашин:

Strange question. What do you expect?

I'm 100% sure it won't...

Well, then you've appointed yourself right and there's no question.

There's nothing to argue about. The result is already there and there will be more to come. Let's test it as we planned and do a good deed for the community.

Zy. However, you can refuse.
 
Who cares what my approach is anymore? What kind of dogmatism is this? Worship a bunch of English-speaking scientists who projected their own subjective understanding of the object and always be secondary, thinking that they have a monopoly on introducing concepts into programming? And if someone who is cooler than them can philosophize and present the object in a simpler and more efficient way? What if someone wants to write a program in their own language?

Ah, never mind. If ego is putting a spoke in the wheel here, then what good is the result...
 
I will, of course, solve the tasks at hand. The testers will be found.
 

Peter, you have a very interesting reaction, as they say "and then Ostap got carried away". There's a hint of some childish, primitive resentment. But to what?

I simply wrote that I do not believe that the twisting of conventional concepts justifies the result.

If I understand correctly, you are not trying to develop a separate system but a toolkit for other programmers.

But other programmers, potential users of your product already at this stage say: Peter - this is not right! You, in response, say: "But you guys are all incompetent, you don't know a shit about programming and have invented for yourselves somehow RPF and classes! But everything is actually simple and easy to do in assembler. I'll finish my product and teach you new programming rules, otherwise you all play in a sandbox and don't see any further than your nose!"

Somehow it all sounds like that.

But you don't understand the main point: those who will use your product according to your idea, have a completely different understanding of programming and the concept of "object", the event model, event subscriptions, inheritance, etc. It will be very difficult for them to switch from conventional paradigms to a single product with some twists.

I'm sure the editor itself will be excellent, there's no doubt about that. As a standalone product it can be respected and you can even play with it as a constructor. But learning something new like a "markup language" just to connect the GUI to your code would be unprofitable.

You've done a great job of creating a graphical constructor. Notice how absolutely everybody supports you in this direction.

And practically everybody tells you: Peter, all this would be in demand if you rewrite everything on OOP. But you do not hear me. Apparently, you create a product strictly to satisfy your ego, rather than for other users, whose interests you blatantly and openly ignore.

Well, speaking of the Russian language, you are not a trailblazer here too. The Russian company 1C has long developed a language with programming mostly in Russian.

1...202122232425262728293031323334...58
New comment