Proposal of import library piece

[Timo Virtaneva]

The basic idea of the import is following

1. The start point of the imported pattern will be replaced by the point, where the import will take place. This is like if user will import to point B85, the start point A will be replaced by B85. All points will be drawn from this point as in the imported pattern. The imported pattern points will be renumbered. In this case A1 -> BXX, A2-> BYY ...

2. The pattern could be imported also as new patter piece. In this case only the letter will be replaced accordingly.

3. If the imported pattern will have same Increment value, the imported value will discarded. All other values should be merged to the pattern.

[Roman Telezhynskyi]

Hi,

This is good idea, but it need a lot discussions. Right now i don't have ready view how to implement this.

I see mostly you deal with name collisions. In this case i know better approach - namespaces. How to implement this is another story. ;)

Also the easiest way to import is import as pattern piece.

Another case is extending current pattern. For example you have a base and you say Valentina to continue working based on this file. This way changes in common ancestor will affect all inherited patterns.

Do you want pattern to be included after import or stay in separate files? And what to do in this case when we want to share a pattern. If not include inside we need to share imported modules as well.

[Timo Virtaneva]

I understand that this could be complicated. I would like to start with straight forward solution. This solution can be modified when we have collected more needs.

The need behind this proposal is to have common pieces as library items. These could be - Sleeve - Collar - Pocket, etc.

The imported piece should be merged to the pattern as it would have been drawn. The name collision could be used as a feature. I would use it for passing values to the imported piece. For example I have values ArmSkyeGirth, ArmLegth and CuffGirth in the pattern and have same value in the imported piece. The imported values will be discarded and the sleeve will be drawn correctly in to the pattern.

[Roman Telezhynskyi]

The imported piece should be merged to the pattern as it would have been drawn.

Yes, this is the easiest approach, but usually when someone talks about library components he wants flexibility, be able to modify library components only and this way get all inherited patterns updated automatically.

Don't get me wrong. I don't try to close this proposal. This is very important improvement. And at the same time very complicate. I just have too many questions. Still not sure what we want to build. I predict a lot questions from user, something like "Why i cannot just fix library component and it will be automatically changed in all patterns?"

Usually in situation like this i have a lot doubts at beginning of work. Too many ways to go, too many proposals in my head. And we should kill them all, clear a field and see what is really right. So, talk with me.

Our goal now to describe the whole idea and then split it on easy steps (pieces).

I thought little bit about the proposal. And one thing we should do to become closer is to improve qmuparser. It lacks of user functions like Length(A;B), where A and B are points. Such functions will make possible to easy search and rename points. Right now this is not an easy task.

[Timo Virtaneva]

I see your point. At the moment I'm looking a solution to make patter making a bit easier.

If I want draw jacket, I need to complete the jacket body before I can draw the sleeve. The sleeve is most of the cases the same, but quite complicated to draw. After I have done it, I need to very that I haven't done any mistakes. If I would have tested sleeve, which I can import, it would save a lot of work.

The Library might be too big word for this import function. At the moment I don't see the need as common library, because there are to many different pattern making systems. Mixing the systems might not work.

I would make my own set of patter pieces, which I regularly use to avoid the tedious redraw.

I don't see a need to this "Why i cannot just fix library component and it will be automatically changed in all patterns?" It's because, when I have drawn and tested a pattern, I don't want accidentally change it by library piece change.

This import and merge would be a basic functionality of importing. It can be expanded and modified in the future.

[Roman Telezhynskyi]

Thank you for your feedback. Now i see your point. As i said usually it is easy to come with very big shiny idea that is far from reality.

Just import and merge make all less complicated. Let's think where we have merge conflicts. These are point labels and internal variables, something else? Variable can be 0 if not defined, not a problem. Or even make a pattern piece more or less independent and allow defining increments on level of pattern piece in addition to pattern level. Resolving point labels conflict is tougher task. Right now we don't have tools to make it an easy task. I need to think.

[Roman Telezhynskyi]

I think this proposal is good for Valentina 0.7.0. To resolve issues we have, we will switch to better math parser, i like Lua based most (but this is not finished decision).

[Timo Virtaneva]

Good. I think label conflicts can be solved by adding number in the end. If there will be change label feature someday, user can rename the conflicts.

[Emmanuel Nyachoke]

@dismine This seems like an interesting feature to have. Imagine another case were we have base templates from which someone can create other patterns. That way experienced community members can create templates like basic bodice, basic trousers, basic skirt, basic shirt.. etc. The templates should be fully parametric and well tested this new users get a starting point and the can concentrate on adding their customizations to the patterns. The guys at https://freesewing.org/ are doing something similar but I don't like their approach in that they are creating patterns as code.

[Roman Telezhynskyi]

Many people have different opinion about this feature. Some will suggest to use just pattern as a base. But i think possibility to copy blocks between files would be nice to have. Although, to implement this you must have good knowledge of internals. First of all we don't have such a block. Our patterns are very tied. Valentina is not smart enough to tell you about all dependencies a block has.

[Emmanuel Nyachoke]

Whichever way this is done it is really a cool feature to have

[Светлана Вихарева]

Голосую обеими руками. Возможность работать с блоками шикарна. Это переводит функциональность программы на новый уровень и существенно экономит время на разработку элементов конструкции и вариативность. Посмотрите как реализуется эта задача в грации https://www.youtube.com/watch?v=jTfMQP6JK4M&feature=youtu.be В Леко тоже нет особых проблем с решением этой задачи. Нужна возможность давать имена финальным параметрам и вставлять куски кода шаблонов рукавов, воротников и т. д ну хотя бы на новый слой-выкройку шаблона. А дальше мы сами разберемся. :)) Роман, на самом деле хочу Вас сердечно поблагодарить за программу. Я уже несколько лет работаю в Леко, но несмотря на пока что ограниченный по сравнению с Леко функционал Valtntin-ы, она мне очень нравится, и довольно часто оказывается удобнее в работе чем Леко. Для индпошива и отработки пробников она однозначно более оправдана.

[Светлана Вихарева]

Оператор Если уже реализован в Valentina? Я у Вас на новенького и еще недостаточно ориентируюсь в программе.

[Roman Telezhynskyi]

Оператор Если уже реализован в Valentina? Я у Вас на новенького и еще недостаточно ориентируюсь в программе.

Да. условие ? правда : ложь. Пока что только так.

‌

[Светлана Вихарева]

Спасибо, Роман. Прошу прощения, вот ссылка на того же автора но ролик более полно иллюстрирует решение задачи. https://www.youtube.com/watch?v=qrrorNXXJ8U На самом деле, как вариант, уже сейчас можно строить различные виды рукава или воротника на отдельном слое выкройки и скрывать ненужные части под глазик, но немного хлопотно выбирать из списка готовых деталей нужную именно в данный момент, путаница очень вероятна.