4 ms·

This does not dismiss the rest of his argument. Cross-platform is still an issue even if you don't target the web.

by x7777 5y ago

detaro 5y ago
Qt makes it also easy to build the app cross-platform, so no, it's not really an argument.
- makomk 5y ago
  Also, I suspect the main cross-platform portability issues you're likely to run into with an app like that are differences in filesystem behaviour, and developing it as web app doesn't really help there.
  - x7777 5y ago
    That's a good point - still you'd be sacrificing product development speed for the low level fs access, so the author should really make sure they know how much of it they'll need.
  - x0054 5y ago
    Given that BinFinder only needs the ability to read/write files and scan directories, it should be relatively cross platform out of the box. No real platform specific features, such as soft links, tags, etc necessary. On MacOS the app will likely need to ask for permission to access the disk, that's the only cross platform file system issue I see at the moment.
- paulryanrogers 5y ago
  It depends on how dynamic the UI will be.
  - x0054 5y ago
    I was hoping to design something where on the left side there would be a tree of all the Bins (folders) and user would be able to click check boxes next to the folders they care about and the UI would instantly update with a list of matching Bins on the right side of the UI. Data would be pulled from cache stored in SQLite DB. Can you see any issues with this on either Electron or QT? At first glance it feels like both should ok.
    - paulryanrogers 5y ago
      Should be possible with Qt widgets or Electron. Qt also has its own Electron-like web-based solution. Qt widgets would likely be the fastest and lowest footprint. Though I'm not familiar enough to say exactly how you'd go about that.
    - SXX 5y ago
      Okay I hope you still readind replies so here is that: wanted to reply directly to topic starter since it's most relevant. Some might be taken my posts here like I hate Qt or something, but I really like Qt. I don't see any issues with implementing your idea using Qt and it's will absolutely certainly be using less CPU and RAM without any optimizations. Yet IMHO there is good chance that if you stumble into some Qt / CMake / C++ issue then you gonna be wasting ten times more time on initial implementation. This is C++ for you. And this might kill your project before you even get to first stable version.
- SXX 5y ago
  If your Qt app has single C++ line of code cross platform builds become much harder. Also regardless you still have to solve packaging and updates for Windows, macOS and Linux. Also it's much harder to do QA and it's take much more effort to maintain cross platform Qt app in general. For Electron apps it's all much easier because all native code is heavily tested by other commercial software and there is even on-the-fly updates possible. PS: I shipped C++ apps built using Qt and cross-platform part is huge time sink.
  - Nicksil 5y ago
    How often and to what extent did you build using Qt? Your arguments against using Qt don't align with its actual capabilities. Qt has an extensive API so perhaps you weren't aware Qt possesses such capabilities which would be understandable if your exposure to Qt was transient. >If your Qt app has single C++ line of code cross platform builds become much harder. As I mentioned, Qt has an extensive cross-platform API; indeed that API is Qt's value prop. If you've the need to write arch/platform-specific UI code, then it's very likely you'll find the solution to that problem somewhere within Qt's docs. If not, then you cannot expect to be able to write such code using Electron/JavaScript. >Also regardless you still have to solve packaging and updates for Windows, macOS and Linux. What's to solve? Qt has had these capabilities. If you describe a specific issue, you may have an argument, otherwise this statement makes no claim. >Also it's much harder to do QA and it's take much more effort to maintain cross platform Qt app in general. How so? This is such a broad and unspecific claim to the extent it isn't possible to form a counter argument. State specifically the issues making it much harder to complete these tasks using Qt. >For Electron apps it's all much easier because all native code is heavily tested by other commercial software Qt's testing suite is extensive. Qt is and has been deployed and "heavily tested" around the world for years. Qt is also deployed as an embedded technology. >PS: I shipped C++ apps built using Qt and cross-platform part is huge time sink. I'm not sure you spent much time doing this because Qt makes shipping cross-platform software so simple it sometimes feels like I'm cheating (there are exceptions when dealing with very specific platform/arch-specific items as I mentioned above; there is no solution in JavaScript.). There must be some specific issue(s) you came across, but without specifying what specifically made you perceive using Qt a huge time sink, the statement makes no claim.

This does not dismiss the rest of his argument. Cross-platform is still an issue even if you don't target the web.

by x7777 5y ago

This does not dismiss the rest of his argument. Cross-platform is still an issue even if you don't target the web.

detaro 5y ago

Qt makes it also easy to build the app cross-platform, so no, it's not really an argument.

makomk 5y ago
Also, I suspect the main cross-platform portability issues you're likely to run into with an app like that are differences in filesystem behaviour, and developing it as web app doesn't really help there.
- x7777 5y ago
  That's a good point - still you'd be sacrificing product development speed for the low level fs access, so the author should really make sure they know how much of it they'll need.
- x0054 5y ago
  Given that BinFinder only needs the ability to read/write files and scan directories, it should be relatively cross platform out of the box. No real platform specific features, such as soft links, tags, etc necessary. On MacOS the app will likely need to ask for permission to access the disk, that's the only cross platform file system issue I see at the moment.
paulryanrogers 5y ago
It depends on how dynamic the UI will be.
- x0054 5y ago
  I was hoping to design something where on the left side there would be a tree of all the Bins (folders) and user would be able to click check boxes next to the folders they care about and the UI would instantly update with a list of matching Bins on the right side of the UI. Data would be pulled from cache stored in SQLite DB. Can you see any issues with this on either Electron or QT? At first glance it feels like both should ok.
  - paulryanrogers 5y ago
    Should be possible with Qt widgets or Electron. Qt also has its own Electron-like web-based solution. Qt widgets would likely be the fastest and lowest footprint. Though I'm not familiar enough to say exactly how you'd go about that.
  - SXX 5y ago
    Okay I hope you still readind replies so here is that: wanted to reply directly to topic starter since it's most relevant. Some might be taken my posts here like I hate Qt or something, but I really like Qt. I don't see any issues with implementing your idea using Qt and it's will absolutely certainly be using less CPU and RAM without any optimizations. Yet IMHO there is good chance that if you stumble into some Qt / CMake / C++ issue then you gonna be wasting ten times more time on initial implementation. This is C++ for you. And this might kill your project before you even get to first stable version.
SXX 5y ago
If your Qt app has single C++ line of code cross platform builds become much harder. Also regardless you still have to solve packaging and updates for Windows, macOS and Linux. Also it's much harder to do QA and it's take much more effort to maintain cross platform Qt app in general. For Electron apps it's all much easier because all native code is heavily tested by other commercial software and there is even on-the-fly updates possible. PS: I shipped C++ apps built using Qt and cross-platform part is huge time sink.
- Nicksil 5y ago
  How often and to what extent did you build using Qt? Your arguments against using Qt don't align with its actual capabilities. Qt has an extensive API so perhaps you weren't aware Qt possesses such capabilities which would be understandable if your exposure to Qt was transient. >If your Qt app has single C++ line of code cross platform builds become much harder. As I mentioned, Qt has an extensive cross-platform API; indeed that API is Qt's value prop. If you've the need to write arch/platform-specific UI code, then it's very likely you'll find the solution to that problem somewhere within Qt's docs. If not, then you cannot expect to be able to write such code using Electron/JavaScript. >Also regardless you still have to solve packaging and updates for Windows, macOS and Linux. What's to solve? Qt has had these capabilities. If you describe a specific issue, you may have an argument, otherwise this statement makes no claim. >Also it's much harder to do QA and it's take much more effort to maintain cross platform Qt app in general. How so? This is such a broad and unspecific claim to the extent it isn't possible to form a counter argument. State specifically the issues making it much harder to complete these tasks using Qt. >For Electron apps it's all much easier because all native code is heavily tested by other commercial software Qt's testing suite is extensive. Qt is and has been deployed and "heavily tested" around the world for years. Qt is also deployed as an embedded technology. >PS: I shipped C++ apps built using Qt and cross-platform part is huge time sink. I'm not sure you spent much time doing this because Qt makes shipping cross-platform software so simple it sometimes feels like I'm cheating (there are exceptions when dealing with very specific platform/arch-specific items as I mentioned above; there is no solution in JavaScript.). There must be some specific issue(s) you came across, but without specifying what specifically made you perceive using Qt a huge time sink, the statement makes no claim.