+- TACTIC Open Source (http://forum.southpawtech.com)
+-- Forum: TACTIC Open Source (http://forum.southpawtech.com/forumdisplay.php?fid=3)
+--- Forum: TACTIC Discussion (http://forum.southpawtech.com/forumdisplay.php?fid=4)
+--- Thread: TACTIC Bugs (/showthread.php?tid=216)
RE: TACTIC Bugs - Diego - 06-11-2021
Listy looking at TacticHandler I wouldn't say you have "little experience in python"
I did some full stack development Python/CherryPy/Flask server side and Bootstrap/Angular client side, never used React or Vue, and I admin I don't particularly like doing web development.
Since Remko mentioned they are going with React I guess we can start learning it...
RE: TACTIC Bugs - remkonoteboom - 06-11-2021
Yes, as I have mentioned, the VFX plugin is outdated. As I know we are all busy, but it would be great to update the VFX Plugin so that it is more modern and provide a better open source alternative to what is on the market today.
I have done a fair amount of React programming over the last year or so. Over the last couple of years, React has changed the paradigm of how to do front end UI. With a React UI, we have two choices. First: run a completely separate NodeJS server which access the TACTIC server through the API. All of my projects with React so far have done this. However, this approach does require a more complicated setup. There are authentication issues as well as running a separate service. If you know what you are doing, this isn't that difficult, but it is something to be aware of.
Another approach that I have had some minor success at is to integrate React directly into TACTIC widgets. At present this, works if you use pure javascript React. This does have benefits in that the interface is more fluid (and it will work with Bootstrap Material Design as well) ... however, it is currently lacking a JSX processor. If you know react, this is much easier to use and most people using React will be used to this. To get a JSX processor, we need to use PyV8 and V8 Chromium, however, I haven't been able to get that to work. Here is rather old announcement (2013):
https://reactjs.org/blog/2013/08/19/use-react-and-jsx-in-python-applications.html
Anyway, that's a rather deep technical dive into why React isn't currently more used in the TACTIC interface. Until the above is figured out, React will be a bit difficult to integrate directly with TACTIC.
RE: TACTIC Bugs - remkonoteboom - 06-11-2021
I should mention, I am very enthusiastic that there has been a lot of renewed interest and thanks Diego for contributing pull requests. Contributions such as this and honest open feedback is very welcome. Please submit bugs and feature requests to GitHub and general discussions should happen here.
RE: TACTIC Bugs - listy - 06-11-2021
(06-11-2021, 03:28 PM)remkonoteboom Wrote: I should mention, I am very enthusiastic that there has been a lot of renewed interest and thanks Diego for contributing pull requests. Contributions such as this as honest open feedback is very welcome. Please submit bugs and feature requests to GitHub and general discussions should happen here.I would do a huge amount of edits and stuff if I understood how frontend of TACTIC are working and had experience with JS.
At the moment, any change to TATIC UI is a big effort for me.
And I (not just me but also users of my setup of TACTIC) am very, very happy with the way the bug fixes appear.
Most of the bugfixes, e.g. messages or gallery, are work blockers. And have been much waited
RE: TACTIC Bugs - remkonoteboom - 06-11-2021
Part of the problem is that the VFX module does not use Custom Layout widgets very much, if at all. This makes it very difficult to understand the structure of the VFX workflow. The first thing I think needs to be done is to start wrapping all the sidebar links into corresponding CustomLayout wrappers so there is direct relationship between these. All of our projects have done this for a while, while we haven't ported the VFX module to do this.
Once this is done, the structure of the VFX module would be much more understandable, even if some of the real processing occurs deep on the Python code, but it allows for a much better understanding of how the module is put together. This can be done incrementally, which I will start.
As Diego has mentioned, the VFX module must be moved from the template to a full plugins implementation.
RE: TACTIC Bugs - listy - 06-11-2021
(06-11-2021, 03:44 PM)remkonoteboom Wrote: Part of the problem is that the VFX module does not use Custom Layout widgets very much, if at all. This makes it very difficult to understand the structure of the VFX workflow. The first thing I think needs to be done is to start wrapping all the sidebar links into corresponding CustomLayout wrappers so there is direct relationship between these. All of our projects have done this for a while, while we haven't ported the VFX module to do this.This is cool!
Once this is done, the structure of the VFX module would be much more understandable, even if some of the real processing occurs deep on the Python code, but it allows for a much better understanding of how the module is put together. This can be done incrementally, which I will start.
As Diego has mentioned, the VFX module must be moved from the template to a full plugins implementation.
To be honest, i am not using VFX template, and my my own from scratch. (without plugins system)
That is again was done because i experienced LOTS of bugs with VFX template, and it was not usable.
And template-based system was used because there was no examples of how to use plugins-based projects...
Having Examples is 99% of success, there was Virtual machine with lots of TACTIC examples and it has lots of useful stuff.
RE: TACTIC Bugs - Diego - 06-11-2021
(06-11-2021, 03:44 PM)remkonoteboom Wrote: Part of the problem is that the VFX module does not use Custom Layout widgets very much, if at all. This makes it very difficult to understand the structure of the VFX workflow. The first thing I think needs to be done is to start wrapping all the sidebar links into corresponding CustomLayout wrappers so there is direct relationship between these. All of our projects have done this for a while, while we haven't ported the VFX module to do this.
Once this is done, the structure of the VFX module would be much more understandable, even if some of the real processing occurs deep on the Python code, but it allows for a much better understanding of how the module is put together. This can be done incrementally, which I will start.
As Diego has mentioned, the VFX module must be moved from the template to a full plugins implementation.
Sounds nice.
If you port one sidebar link to a corresponding CustomLayout to make me understand how to standardize it I could port the rest of the plugin myself following your example.
RE: TACTIC Bugs - remkonoteboom - 06-14-2021
I just created an pull request which does moves some views to use a custom widget first. The basic issues with the VFX module is that the sidebar is configured to directly open a "ViewPanelWdg" into a new tab. This can be seen in the widget_config table width the criteria of:
category = "SideBarWdg"
view = "definition"
This entry defines what the side links will open up when clicked. So what I had to do was remap the definition entry to point instead to a CustomLayout view like this:
Code:
<element name="shot" icon="FAS_VIDEO" title="Shots" state="">
<display class="LinkWdg">
<widget_key>custom_layout</widget_key>
<view>vfx.shot.main</view>>
</display>
</element>This will now use the "vfx.shot.main" view definition in Custom Layouts. The use of custom layouts is much cleaner because you get a nice folder structure for defining the structure of your project. You can also easily add html, css, client side javascript and server side python code into a single view. In this case, the shot view became:
Code:
<div class="card vfx_shot_list_top">
<element>
<display class="tactic.ui.panel.ViewPanelWdg">
<title>SHOTS</title>
<search_type>vfx/shot</search_type>
<simple_search_view>shot_custom_filter</simple_search_view>
<view>shot</view>
<use_last_search>false</use_last_search>
</display>
</element>
</div>I did this for both the sequence view and shot views and I also added a rudimentary dashboard.
Take a look and ask if anything doesn't make sense. I will continue to do work on this when I can.
RE: TACTIC Bugs - Diego - 06-18-2021
That's very clear.
I just made a PR:
- Made asset a custom view on par with shot a sequence
- Added link for asset from dashboard
- Removed home view as it was a duplicate of dashboard
- Added an icon to dashboard
- added back vfx/config/config_widget.spt as is still needed
I added vfx/config/config_widget.spt because:
- many links still go to the ViewPanelWdg
- New custom layouts use a ViewPanelWdg which needs configurations
I guess we could get rid of more config_widget entries configuring ViewPanelWdg "inline" into the custom widget, is this a good idea? We would still need a definition and an edit_definition to configure widget used in ViewPanelWdg columns.
One question what does <use_last_search>false</use_last_search> do?
RE: TACTIC Bugs - remkonoteboom - 06-18-2021
Unless there is a need to have a reusable table view that will be in many custom layouts, I often prefer to decide which columns will be present inline using element names. In this example:
Code:
<div class="card vfx_shot_list_top">
<element>
<display class="tactic.ui.panel.ViewPanelWdg">
<title>SHOTS</title>
<search_type>vfx/shot</search_type>
<simple_search_view>shot_custom_filter</simple_search_view>
<view>shot</view>
<use_last_search>false</use_last_search>
</display>
</element>
</div>We are using the "shot" view. There is nothing wrong with this as it allows you use the "shot" view in multiple places ... if you do have another view, you can always use:
Code:
<element_names>preview,code,status</element_names>In this case, it would only display the elements list here (preview,code,status), but cascade to "shot" view for the definition and if an element doesn't exist, it will cascade to the "definition" view.
Generally, the "definition" view will contain all the base definitions. However, as you can see in the current "definition" entry for shot, it has, over the years, become a monstrosity. If an element definition will only be used once, it is probably best to create a new "view" with that one entry. The <element_names> tag removes the vast majority of needs to have a separate view for a given widget.
In the end, none of it is wrong. It is just a matter of design and readability. I prefer to keep local definitions as local as possible and reserve "definition" for the global definition (the exact opposite of what we see in the VFX module). So, delete element entries and views as you see fit, if they are redundant.