상용 IDE가 필수네요.
그것도 비교적 최신 버전으로요. ㅎㅎ
UI를 갈아엎기 위해 조사하다보니 이게 딱 걸리네요.
다른쪽으로도 많이 쓸거라면 구매하자고 할탠데…
그럴 상황도 아니고 팀장을 비롯한 팀원들이 썩은물이라 새로운것에 관심도 없고요.
뭐 플러터랑 우노밖에는 안 남는데. 이러면 플러터로 가는게 맞지 않을까?
생각이 됩니다.
6개의 좋아요
각 프레임워크가 제공하고자 하는 컨셉을 바탕으로 풀이하려는 비즈니스에 유리한지 확인하고 선택하는 것을 제안드립니다.
예로 우노는 윈도우즈 중심으로 통합했어요. 모바일만 서비스할 계획이라면 독이 될 수 있습니다.
4개의 좋아요
기존 프로그램이 C++로 되어 있고 윈도우즈 만 지원 합니다. 정확히는 윈도우즈 7이상요.
그걸 이번에 새로 만드는데. 어차피 코어는 c++로 새로 짜야 하는 부분이고
또 C++은 제대로 된 UI가 이제는 거의 안 나오니 UI와 통신 같은 부분을 전부 새로 하자고 한 거죠.
뭐 이러하니 선택 조건이 상당히 널널합니다. (어차피 새로하는데 다른 언어와 프레임웍을 쓰자고 제가 꼬드긴 겁니다. C++로 하면 또 똑같아 질거라…)
아~ 그리고 모바일은 아예 별도의 팀이 있습니다.
3개의 좋아요
그러면 그냥 winui가 답일수도…
2개의 좋아요
WinUI 3의 경우 윈도우10 이상만 지원하므로
의외로 WPF가 답일 수 있습니다.
2개의 좋아요
제가 꼬드기는것의 한계점 입니다. ㅎㅎ
C#은 저만 하는지라…
WPF도 있고 뭐 그런 얘기 해 봤지만… 쌩뚱맞게 MAUI를 보는 사람이 조사중이라서요.
말을 원래 안들어 먹는 사람이라 제가 이정도 선까지 꼬신것도 기적적이라 생각 중 입니다.
제 입장에서는 WPF가 제일 쉽긴 합니다만… 아마 그러면 제가 독박을 쓰게 될 겁니다.
4개의 좋아요
c++로 dll 만들어서 메인 UI 프로그램이 dll 호출하거나 콜백함수 등록해서
호출되게 하는 방식인가요?
제가 이런 방식으로 개발하는데 괜찮은거 같더군요.
2개의 좋아요
맞습니다. 그런 방식입니다.
현재 프로그램은 C#으로도 가능은 한데… 코어단을 별도로 만드는게 더 합리적인 프로그램이라서요.
저도 여러가지로 해 봤는데.
하드웨어 제어가 많거나 C/C++라이브러리 사용이 많을 경우 그냥 임포트 시켜서 쓰는게 가장 합리적이더군요.
2개의 좋아요
말씀해주신 환경이라면 저도 WPF가 가장 낫지 않을까 싶습니다.
아무래도 레퍼런스 양의 차이가 꽤 있기도 하구요, MAUI나 AvaloniaUI를 쓰게 되면 개발 도중에 문제가 생겼을 때 원인을 찾기도, 해결하기도 힘든 상황이 종종 생기지 않을까 싶습니다.
2개의 좋아요
댓글 보니 C++ native WinUI 3 unpackaged로 만드는 게 낫겠네요
WinUI 3 버그도 많이 잡힌 거 같고 인하우스에선 쓸만한 것 같습니다.