Make this project actually cross platform about docxtosource HOT 7 OPEN

I'm interested in helping. I suggest we try and use one of the popular JavaScript frameworks like Angular or React. We also need to leverage docker-hub and travis-ci.com to containerize the dev environment for everyone and get the builds automated Looks like a lot of initial work, but Ive seen first hand this tech pay off in the end on multiple projects.

I did silverlight/.net dev in the past want to get away from windows/visual studio development lock-in with nascent xaml / wpf or rasor based frameworks. Using JavaScript/Docker/CI pipelines with VSCode will help open this up so more devs can help and more cross platform UI options in the end.

Ill subscribe here to see what is decided. In the meantime, I want to do some test forks for feasibility. I dont have a ton of free time, but will keep an eye on this and help when I can regardless of what path is chosen.

from docxtosource.

Hello! I created Avalonia version https://github.com/rstm-sf/DocxToSource.Avalonia

from docxtosource.

Thank you for your feedback, @thomasbtatum.

I was thinking of using a JavaScript/TypeScript frontend with a asp.net webapi backend when I listed the Electronnet option, but looking at it now, it doesn't look that clear. And I believe that you are correct in that it would open this up to more people to help with this project also. I would welcome this approach if it proved popular enough with others.

I'm going to modify the original list of options to make this approach more clear.

from docxtosource.

Hello! I created Avalonia version https://github.com/rstm-sf/DocxToSource.Avalonia

That's awesome. Can't wait to try it out!

If it works well on both Windows and non-Windows machines (i.e.: Linux), it may be good to create an organization umbrella for the 3 projects (DocxToSource.Wpf, DocxToSource.Avalonia, and Serialize.OpenXml.CodeGen) instead of having them scattered between user accounts. We can talk this further if interested.

Thanks,
Ryan

from docxtosource.

I think this should work well on all platforms since no OS specific was used (except perhaps OpenFileDialog?). I know that to make it easier for users to use macOS, it is necessary to build bundle, but I have never used this OS and therefore there is no practice.

The code from the repository can be added to this, but it seems to me that we still need to separate MVVM project for this, leaving the WPF/Avalonia specific code. For example, the TreeViewItem controls can be replaced with a node model (is it possible to adapt to WPF?). Also, from Languages ​​and MainWindowModel, we can also select the services AvalonEdit/AvaloniaEdit and OpenFileDialog. And finally, choose the MVVM framework — we can leave the current (I'm equally bad at Prism, CommunityToolkit.Mvvm and ReactiveUI :) but they are all there for Avalonia)

from docxtosource.

I think this should work well on all platforms since no OS specific was used (except perhaps OpenFileDialog?). I know that to make it easier for users to use macOS, it is necessary to build bundle, but I have never used this OS and therefore there is no practice.

I agree, that was the main reason why I was looking at Avalonia in the first place. I used Mac OS X before but it's been such a long time that I feel like my experience is now out of date. However, we can focus on Windows/*nix for now while we figure out the macos angle. We may need to make a call for help later for this depending on how far we get.

The code from the repository can be added to this, but it seems to me that we still need to separate MVVM project for this, leaving the WPF/Avalonia specific code. For example, the TreeViewItem controls can be replaced with a node model (is it possible to adapt to WPF?). Also, from Languages ​​and MainWindowModel, we can also select the services AvalonEdit/AvaloniaEdit and OpenFileDialog. And finally, choose the MVVM framework — we can leave the current (I'm equally bad at Prism, CommunityToolkit.Mvvm and ReactiveUI :) but they are all there for Avalonia)

Yeah, I can see that. We can take a look at how to organize this code to see how best to reduce redundency. However, I would still look into creating a new organization and moving the projects there. I would feel bad if it was still housed on my user account and hold up dev if I don't have time to work on it. Maybe something simple as docxtosrc or something along those lines?

Thoughts?

from docxtosource.

Hi @rstm-sf,

I just made a new org, Docx2Src that I plan on moving this project and Serialize.OpenXml.CodeGen to soon. It would be great if we could also migrate your Avalonia work to there as well, if possible. It'll take some planning as to how to organize it the best way possible. Thoughts?

from docxtosource.