As I wrote skad. Part Eight ...
Good day, everyone! Today is Friday, and the best traditions of Habr, I hope my today's post will be a good topic at the end of the work week! More than a year has passed since my last publication, and during this time quite a lot of new interesting events have occurred, which I would like to tell now to all those who continue to follow the topic.
All previous my articles on this topic can be found through the search.
I want to start by saying that at the end of last year some critical mass had matured, which made me sit down and start the process of releasing a new version of my scad system. The experience and achievements accumulated during this time became the basis for a completely new product concept, but under the condition of preserving its architectural integrity and ideology. So, now preparing for release a new version of my Scud at number 2.0!
It was seriously reworked quite a bit, although I would even prefer a simple concept - it was written anew. Yes, there were ideas, there were prototypes, there was a ready-made working and self-proven in combat tests and real-world applications architecture and product. On the basis of all this, as well as my new crazy ideas - now a completely new system is being written, but taking into account all of the above.
')
Itching very much to redo the single editor of the project - it was necessary to bring it to the concept of MDI. This required usability, and indeed common sense. Also, the idea of ​​a completely new graphical interface engine has long been in the air. In my previous articles, I made some notes about this and showed my approximate prototypes. Now, these ideas and prototypes formed the basis of the new architecture of the graphics engine and the graphics editor itself. Using the graphic artwork - of course, the algorithm editors were modified, both graphical (FBD) and script (C #). So far, everything here has been limited to usability and frills, but I began to lay the foundation for the algorithmic engine of the new system for further expansion of its capabilities, but this will be the topic of future articles (I hope).
The most important thing that seriously slowed me down was the way to develop a new version - this is the mistake that many developers of such systems make when it comes to the stage of development and development of new versions - the continuity of these versions. This is a very serious stumbling block, which on any smooth road gives a serious hindrance, about which almost everybody stumbles on it. It is very difficult to make a new one that will not deny or not support the old, often because this is really new and the old can not be squeezed into the framework of this new concept. But the majority of users are not old and new, but this is an unbroken line that stretches from the old to the new and cannot just take it and interrupt, because the product developer decided that the new will be like that and everything old needs to be redone, or give up him This problem slowed me down quite seriously. But, I helped her a little bit and decided to try one interesting way, which, I think, will be able to minimize problems when switching to a new system. And even more so - the new system will be able to integrate into existing old versions of projects and gradually, step by step, will give the developer the opportunity to make a smooth transition to the new version of existing and existing systems. But the details of this idea are a little further in the text.
The transfer of the development environment to a multi-document architecture demanded some fuss, and judging by the current state of these cases, the fuss with the small things remains to be done. But, at least, the organization of the system windows and their docking - now looks and works like a human being. Unfortunately, I now do not have so much free time, so this article will not be replete with pictures and videos, I will try to show a little, but for specific things:
The most basic part of the system, which was rewritten from scratch. And it’s not even just rewritten - I created, in fact, a completely new graphic engine of the system based on new technologies for me. At the same time, I tried to lay in it ideas that would become the basis for realistically separating engineering and design work into two separate directions, but aimed at a single result in the development of user interfaces.
I, as a practical engineer, have long believed that the creative component is not subject to education and training, talent is not born in the course of stubborn laborious developments. So skill can be born and improved, no more. Though pick me with a fork, but no one will ever convince me that talent can be grafted and improved. I do not believe in a competent engineer who draws a beautiful, and most importantly convenient interface! In practice, I have not seen this. Come up with an idea of ​​its convenience - yes! Draw - NO! Categorically! This is a talent! And he - a rare thing in combination with engineering thought. Therefore, always sought to ensure that the work on the development of graphical interfaces was always divided into two areas: design, implementation. As the saying goes: Caesar is a Caesar, and a locksmith is ... And this is the only way to make it comfortable, beautiful and functional. And both of these components should make two people of different profession: a designer (design) and an engineer (implementation). In the new graphics system, I decided to simplify as much as possible the support of transitions from the design layout to its implementation and vice versa, to make it transparent. That is, what the engineer makes sketches - can be transferred as is (in the vector, not drawings) to the designer, and then returned from the designer as is (in the vector, not drawings) back to the scud, and continue editing the graphics using the scud further without breaking what the designer did. Today, everywhere, where it comes to similar methods of interface development - the exchange with the designer and back is carried out only at the level of graphic images, which are used maximum as a substrate, or as a background, no more. I want engineers to stop being artists, and do their tasks, and artists could most adequately accept and return models to engineers. This is one of the goals of the future system.
And the second main task of graphics in the new system is to reduce the processor load. In the current 1st version of my scud, all the graphics are processor-dependent, so this began to show up in large solutions. It also influenced the interactive features of the graphical interface, limiting some of the possibilities for user interaction.
In this part, all the improvements basically affected only the appearance of the display and the convenience of working with algorithms: for the visual language, a new graphical shell and drawing, and for text, a new editor with its own studio-style buns. Also, within the framework of the new version, I began to work out some new things that the users asked for, although for now I only do them at the core level of the calculator and have not yet brought them out. I plan that soon it will be possible to develop my own FBD blocks based on the scripting language, and also to connect the scripting language to graphic screens, where you can work directly with their contents, or, on the contrary, add custom components to the interface.
As already said above - one of the common problems of most developers of scad is to support the inheritance of developments when switching to new versions. All declare that inheritance is and it is possible to transfer everything old to new, but, as practice shows, the list of “nuances” and “restrictions” often negates such statements, and even what seems to be, can be used no more than "Play around." I do not assert that this is a universal problem, but - it often takes place and very often.
For myself, I decided that to make this business more or less competently will allow only one thing - to prohibit, at the time of development, to load and save the system projects in its native format, and to load projects only in the format of the previous version. Even to debug some function, you must first create a project with it in version 1.0 and only then open it in version 2.0 and perform the check. And if the function is completely new, then to test create a simple project from scratch.
At least, this restriction makes it necessary to work out the support of old developments with their conversion into new formats and so far it seems to be working out.
By the end of this month I plan to distribute a preliminary version for testing among system users and get feedback. But this will be done only among those who are now really working with the current 1st version of the system.
In addition to compatibility - it was decided that at the network protocol level the new version will fully comply with the specification of version 1. This will make it possible, having ready-made operating time in version 1, open it in new version 2.0 and convert, for example, AWP nodes, or add new ones with new graphics and launch them already within the framework of a really working system. Thanks to the support of the same specification - this procedure should provide a smooth transition to the new version of the system without breaking everything that is, and global shoveling and redoing of everything in a row. Let's see if my idea will justify itself. Practice will show, as well as feedback from developers and users too.
All previous my articles on this topic can be found through the search.
I want to start by saying that at the end of last year some critical mass had matured, which made me sit down and start the process of releasing a new version of my scad system. The experience and achievements accumulated during this time became the basis for a completely new product concept, but under the condition of preserving its architectural integrity and ideology. So, now preparing for release a new version of my Scud at number 2.0!
It was seriously reworked quite a bit, although I would even prefer a simple concept - it was written anew. Yes, there were ideas, there were prototypes, there was a ready-made working and self-proven in combat tests and real-world applications architecture and product. On the basis of all this, as well as my new crazy ideas - now a completely new system is being written, but taking into account all of the above.
')
Itching very much to redo the single editor of the project - it was necessary to bring it to the concept of MDI. This required usability, and indeed common sense. Also, the idea of ​​a completely new graphical interface engine has long been in the air. In my previous articles, I made some notes about this and showed my approximate prototypes. Now, these ideas and prototypes formed the basis of the new architecture of the graphics engine and the graphics editor itself. Using the graphic artwork - of course, the algorithm editors were modified, both graphical (FBD) and script (C #). So far, everything here has been limited to usability and frills, but I began to lay the foundation for the algorithmic engine of the new system for further expansion of its capabilities, but this will be the topic of future articles (I hope).
The most important thing that seriously slowed me down was the way to develop a new version - this is the mistake that many developers of such systems make when it comes to the stage of development and development of new versions - the continuity of these versions. This is a very serious stumbling block, which on any smooth road gives a serious hindrance, about which almost everybody stumbles on it. It is very difficult to make a new one that will not deny or not support the old, often because this is really new and the old can not be squeezed into the framework of this new concept. But the majority of users are not old and new, but this is an unbroken line that stretches from the old to the new and cannot just take it and interrupt, because the product developer decided that the new will be like that and everything old needs to be redone, or give up him This problem slowed me down quite seriously. But, I helped her a little bit and decided to try one interesting way, which, I think, will be able to minimize problems when switching to a new system. And even more so - the new system will be able to integrate into existing old versions of projects and gradually, step by step, will give the developer the opportunity to make a smooth transition to the new version of existing and existing systems. But the details of this idea are a little further in the text.
Unified development environment with support for MDI.
The transfer of the development environment to a multi-document architecture demanded some fuss, and judging by the current state of these cases, the fuss with the small things remains to be done. But, at least, the organization of the system windows and their docking - now looks and works like a human being. Unfortunately, I now do not have so much free time, so this article will not be replete with pictures and videos, I will try to show a little, but for specific things:
New graphics engine
The most basic part of the system, which was rewritten from scratch. And it’s not even just rewritten - I created, in fact, a completely new graphic engine of the system based on new technologies for me. At the same time, I tried to lay in it ideas that would become the basis for realistically separating engineering and design work into two separate directions, but aimed at a single result in the development of user interfaces.
I, as a practical engineer, have long believed that the creative component is not subject to education and training, talent is not born in the course of stubborn laborious developments. So skill can be born and improved, no more. Though pick me with a fork, but no one will ever convince me that talent can be grafted and improved. I do not believe in a competent engineer who draws a beautiful, and most importantly convenient interface! In practice, I have not seen this. Come up with an idea of ​​its convenience - yes! Draw - NO! Categorically! This is a talent! And he - a rare thing in combination with engineering thought. Therefore, always sought to ensure that the work on the development of graphical interfaces was always divided into two areas: design, implementation. As the saying goes: Caesar is a Caesar, and a locksmith is ... And this is the only way to make it comfortable, beautiful and functional. And both of these components should make two people of different profession: a designer (design) and an engineer (implementation). In the new graphics system, I decided to simplify as much as possible the support of transitions from the design layout to its implementation and vice versa, to make it transparent. That is, what the engineer makes sketches - can be transferred as is (in the vector, not drawings) to the designer, and then returned from the designer as is (in the vector, not drawings) back to the scud, and continue editing the graphics using the scud further without breaking what the designer did. Today, everywhere, where it comes to similar methods of interface development - the exchange with the designer and back is carried out only at the level of graphic images, which are used maximum as a substrate, or as a background, no more. I want engineers to stop being artists, and do their tasks, and artists could most adequately accept and return models to engineers. This is one of the goals of the future system.
And the second main task of graphics in the new system is to reduce the processor load. In the current 1st version of my scud, all the graphics are processor-dependent, so this began to show up in large solutions. It also influenced the interactive features of the graphical interface, limiting some of the possibilities for user interaction.
New algorithm editors
In this part, all the improvements basically affected only the appearance of the display and the convenience of working with algorithms: for the visual language, a new graphical shell and drawing, and for text, a new editor with its own studio-style buns. Also, within the framework of the new version, I began to work out some new things that the users asked for, although for now I only do them at the core level of the calculator and have not yet brought them out. I plan that soon it will be possible to develop my own FBD blocks based on the scripting language, and also to connect the scripting language to graphic screens, where you can work directly with their contents, or, on the contrary, add custom components to the interface.
Compatible with previous version.
As already said above - one of the common problems of most developers of scad is to support the inheritance of developments when switching to new versions. All declare that inheritance is and it is possible to transfer everything old to new, but, as practice shows, the list of “nuances” and “restrictions” often negates such statements, and even what seems to be, can be used no more than "Play around." I do not assert that this is a universal problem, but - it often takes place and very often.
For myself, I decided that to make this business more or less competently will allow only one thing - to prohibit, at the time of development, to load and save the system projects in its native format, and to load projects only in the format of the previous version. Even to debug some function, you must first create a project with it in version 1.0 and only then open it in version 2.0 and perform the check. And if the function is completely new, then to test create a simple project from scratch.
At least, this restriction makes it necessary to work out the support of old developments with their conversion into new formats and so far it seems to be working out.
By the end of this month I plan to distribute a preliminary version for testing among system users and get feedback. But this will be done only among those who are now really working with the current 1st version of the system.
In addition to compatibility - it was decided that at the network protocol level the new version will fully comply with the specification of version 1. This will make it possible, having ready-made operating time in version 1, open it in new version 2.0 and convert, for example, AWP nodes, or add new ones with new graphics and launch them already within the framework of a really working system. Thanks to the support of the same specification - this procedure should provide a smooth transition to the new version of the system without breaking everything that is, and global shoveling and redoing of everything in a row. Let's see if my idea will justify itself. Practice will show, as well as feedback from developers and users too.
Source: https://habr.com/ru/post/322056/
All Articles