Show HN: Ship 2.0 – A macOS Native Interface to GitHub Issues(realartists.com)
realartists.com
Show HN: Ship 2.0 – A macOS Native Interface to GitHub Issues
https://www.realartists.com/blog/ship-20.html
105 comments
> I'm assuming you are using the actual end user's token for auth
Yes. 5000 requests seems like a lot, though the GitHub API requires us to be pretty chatty. To show reactions we have to request them for every issue and comment individually, for example. Even doing it on demand (which we do) still requires a lot of requests.
> What sort of security do you have in place to prevent data leaks or malicious access?
We take this really seriously, but it's hard to answer comprehensively in a comment. Short story: Principle of least privilege, encryption where appropriate, strong passwords and 2FA for everything, write-only logging, super strict firewall rules, and parameterized queries.
I've been interested in security for quite a while and even briefly did security consulting, so to the extent I'm able, I've been doing everything as "correctly" as I know how from the beginning.
Yes. 5000 requests seems like a lot, though the GitHub API requires us to be pretty chatty. To show reactions we have to request them for every issue and comment individually, for example. Even doing it on demand (which we do) still requires a lot of requests.
> What sort of security do you have in place to prevent data leaks or malicious access?
We take this really seriously, but it's hard to answer comprehensively in a comment. Short story: Principle of least privilege, encryption where appropriate, strong passwords and 2FA for everything, write-only logging, super strict firewall rules, and parameterized queries.
I've been interested in security for quite a while and even briefly did security consulting, so to the extent I'm able, I've been doing everything as "correctly" as I know how from the beginning.
For whatever this is worth to anyone: there are not a lot of people who run bug tracking services that I would trust with my Github credentials, but Nick is one of them.
> Ship isn't just another GitHub API client app. Ship's custom server code listens and watches for changes from GitHub, and pushes efficient delta updates to clients.
Looks like you connect to their servers for updates.
Looks like you connect to their servers for updates.
I'm not really a GitHub user anyway, but that to me is a complete red flag.
Even if you completely trust the company is doing the right thing with regards to being a man-in-the-middle by design, you're also dependent on them being financially successful and interested in this platform for the app to be useful long term.
Honestly the 'server' part sounds like a solution looking for a problem.
Even if you completely trust the company is doing the right thing with regards to being a man-in-the-middle by design, you're also dependent on them being financially successful and interested in this platform for the app to be useful long term.
Honestly the 'server' part sounds like a solution looking for a problem.
I'm impressed by the thought, care, and craftsmanship that went into this, and all the more so because it's such a seemingly mundane tool. A better bugtracker UX. What makes this a secretly interesting or important problem?
Well, we have complex e-mail clients right?
Imagine if your e-mail client was like the Github issue tracker. This level of pain is what a lot of larger projects go through. You have tags and basic filtering, but the interface has a lot of friction for "power users" of issues.
Think of those projects with 1000 open issues, and how you would want to deal with this quickly. Easy access to certain filters, an interface with less noise, etc.
Imagine if your e-mail client was like the Github issue tracker. This level of pain is what a lot of larger projects go through. You have tags and basic filtering, but the interface has a lot of friction for "power users" of issues.
Think of those projects with 1000 open issues, and how you would want to deal with this quickly. Easy access to certain filters, an interface with less noise, etc.
Serious q - how can I trust your 'Login with GitHub' screen? I'd rather be redirected to my browser, so I can see I'm really logging into GitHub, where, in fact, I normally am anyway. Then you can do the whole oauth thing without me having to trust you don't take my password.
First, we're not stealing your password.
Each of us in the past have used multiple GitHub accounts to partition work and personal life, or different consulting clients. I kept them in independent Chrome profiles.
We originally had Ship launch the browser, but it was basically a crap-shoot. I often had to paste the link into a different profile.
That said, you're right. We should allow the option to use the system browser.
From a strict security standpoint though, a malicious native app has remote code execution on your box. It's game over. You're just one local privilege escalation away from complete compromise. At some point you have to trust reputation or never use any software. If this is a concern for you, native apps aren't for you, and that's ok.
Each of us in the past have used multiple GitHub accounts to partition work and personal life, or different consulting clients. I kept them in independent Chrome profiles.
We originally had Ship launch the browser, but it was basically a crap-shoot. I often had to paste the link into a different profile.
That said, you're right. We should allow the option to use the system browser.
From a strict security standpoint though, a malicious native app has remote code execution on your box. It's game over. You're just one local privilege escalation away from complete compromise. At some point you have to trust reputation or never use any software. If this is a concern for you, native apps aren't for you, and that's ok.
> From a strict security standpoint though, a malicious native app has remote code execution on your box. It's game over. You're just one local privilege escalation away from complete compromise. At some point you have to trust reputation or never use any software. If this is a concern for you, native apps aren't for you, and that's ok.
That's a bit disingenuous. The fact that privilege escalations exist doesn't mean one has to trust all the software one uses completely and unconditionally; it means there are risks that should be taken into account.
Given we're talking about the choice between an authentication method where you can trivially capture someone's password, vs an authentication method where you can't (and where you would need to successfully employ some sort of exploit to do so), then the level of risk involved in each is quite different.
(Not only that, but I'd argue people will tend to trust software more when it appears to be making best efforts with regards to security. Any obvious security-related flaws will erode that trust rather quickly.)
(Edit: typos)
That's a bit disingenuous. The fact that privilege escalations exist doesn't mean one has to trust all the software one uses completely and unconditionally; it means there are risks that should be taken into account.
Given we're talking about the choice between an authentication method where you can trivially capture someone's password, vs an authentication method where you can't (and where you would need to successfully employ some sort of exploit to do so), then the level of risk involved in each is quite different.
(Not only that, but I'd argue people will tend to trust software more when it appears to be making best efforts with regards to security. Any obvious security-related flaws will erode that trust rather quickly.)
(Edit: typos)
As a counter point, I have never used multiple GitHub accounts and it's unclear why I would. The separation is provided by contributing to different orgs.
OP, I agree with this. As I mentioned in an earlier comment, I was put on edge using that login screen. There's absolutely no way to know if it's real. I ended up creating a fake GitHub account to test the app because it made me uncomfortable.
This app installed webhooks on all of my repos with no automated way to remove them. Very annoying.
We fucked up here, and I apologize. Many thanks to robbiet480 for writing a script to help clean it up.
We've just pushed new client and server versions to cleanup hooks when the last admin user logs out.
New downloads will be the latest version, and current users can update now using the Ship -> Check for Updates menu option. After that, you can logout using Ship -> Account -> Logout. If you used the app earlier and want to be sure all hooks are cleared out, you can log back in once more and then logout again to trigger the removal.
There is also updated documentation here: https://www.realartists.com/docs/2.0/uninstall.html
So about hooks - Hooks are added so that Ship is alerted when new repos are created, issues/labels/milestones/comments are added/modified/deleted, issue templates change, etc. The user experience without hooks is acceptable, but not great. Presumably if you're using Ship, you want it to show the most up to date information.
We disclose when you authorize Ship that you're granting repository and organization webhook permissions. This appears to be insufficient notice. We'll think about that next.
If anyone is still having trouble or needs personalized help, we're reachable at [email protected].
We've just pushed new client and server versions to cleanup hooks when the last admin user logs out.
New downloads will be the latest version, and current users can update now using the Ship -> Check for Updates menu option. After that, you can logout using Ship -> Account -> Logout. If you used the app earlier and want to be sure all hooks are cleared out, you can log back in once more and then logout again to trigger the removal.
There is also updated documentation here: https://www.realartists.com/docs/2.0/uninstall.html
So about hooks - Hooks are added so that Ship is alerted when new repos are created, issues/labels/milestones/comments are added/modified/deleted, issue templates change, etc. The user experience without hooks is acceptable, but not great. Presumably if you're using Ship, you want it to show the most up to date information.
We disclose when you authorize Ship that you're granting repository and organization webhook permissions. This appears to be insufficient notice. We'll think about that next.
If anyone is still having trouble or needs personalized help, we're reachable at [email protected].
Have you considered only adding webhooks per-repo, and not globally? I have access to numerous repos that I don't want or need real-time updates from, as well as repos from organisations that have added me which I would really rather not touch. They would probably not be happy that their repos are suddenly sending data to a third party that they didn't consent to.
I would love something like Ship for my main public repo, and in fact would prefer to just use Ship for that repo.
I would love something like Ship for my main public repo, and in fact would prefer to just use Ship for that repo.
People are used to granting access to an app without assuming that it's going to take full advantage of that access. I have access to a lot of repos. Like, a LOT of repos with a lot of collaborators. And I just had some app add webhooks to every single one. I'm glad I could remove them with 'logout', but I would have really appreciated a more obvious message.
I wish we'd see this more often. You fucked up, but came clean about it, apologized, and gave a working solution. Congrats!
I didn't want to wait for a solution that may never come for the webhooks added to 200+ repos of mine/that I have access to, so I hacked this script together.
https://gist.github.com/robbiet480/2f095c910e56255c412d85040...
https://gist.github.com/robbiet480/2f095c910e56255c412d85040...
Thanks, and sorry. You shouldn't have had to write this.
You're right, and we're working on a solution for this now.
In the meantime I suggest you warn trial users about this. I had to manually remove it from 40 repositories.
I dearly hope the solution involves not installing webhooks on all one's repositories.
Not sure I understand what the webhook is for. (I've not yet installed the app — because of this issue.) Is this done in order to automatically track Github issue changes? If so, what happens if you want to use this app on a project that you don't have admin rights to?
Not sure I understand what the webhook is for. (I've not yet installed the app — because of this issue.) Is this done in order to automatically track Github issue changes? If so, what happens if you want to use this app on a project that you don't have admin rights to?
Please work faster, I wasn't alerted that a webhook would be added and now I have 200+ repos that need to have a webhook removed...
I was about to download but I saw this comment. Thank you sir.
Yeah… I downloaded but immediately uninstalled after wanting to connect and access data for my private repos. No thanks — I have multiple revenue-generating side projects that are developed on GitHub. I just couldn't get myself to push that authorize button. (I know this is partly on GitHub, but still.)
Can the OP respond to this? I have _tons_ of repos and don't want to end up in the same situation.
Fred, James and I are in the thread and happy to answer any questions about the product and how we built it. There's definitely more detail than made sense to include in the blog post.
I'm fascinated by how it looks almost confusingly similar to Mail.app. Of course a lot of apps use a three-pane layout, but most seem to deviate from the standard UI one way or another. I don't mean not to criticise it - it definitely makes it fit right in as a native Mac app, but it makes me interested in your thinking behind it.
It's possible that Mail.app was a source of inspiration, and that we often found ourselves asking, "Oh, that's like <feature> in email. How do other apps do it?"
This looks very nice! Is there an option to not send data via your server? Some Enterprise deployments I know would not play along with that…
Right now we only support public GitHub, though we're open to considering supporting GitHub Enterprise - perhaps even with an on premises installation. Please reach out to [email protected] if you'd like to talk about it.
Any chance of GitHub Enterprise or Gitlab support?
This looks cool, but superficially very similar to GitScout. Can you talk about what differentiates your product from that one? I'm not trying to be negative, but as a user of that program, I just want to know a bit more about the differences I can expect before I invest the time to trial your product.
Sure. The unique thing about Ship is that it is backed by a continuously synchronized local database of your issues, across all of your repos. This lets Ship run incredibly quickly. Because all of your data is already on hand and up to date, you never wait on the network.
Thanks for offering! Any thoughts on supporting GitHub Projects?
They're kind of supported right now - in that they do show in the app and you can interact with them.
As the GitHub APIs for projects stabilize we'll look into more formal support.
As the GitHub APIs for projects stabilize we'll look into more formal support.
I got as far as the screen where is asks for full read/write access to my code, including all my private repos. I'm fairly sure you won't mess anything up or steal my secrets, but why does it need this?
Sadly, with the current GitHub OAuth flow that's the minimal permission needed to access GitHub Issues.
See https://developer.github.com/v3/oauth/#scopes
See https://developer.github.com/v3/oauth/#scopes
That's what stopped me from using this app. I can't give it access to most of private repos (because NDA and other stuff), and don't have any plans to use it with that repos.
What I wanted to play with some public repos, just to see how it works. Apparently I can't do it w/o giving access to private repos too.
> Ship 2.0 is two parts, a hybrid Cocoa/ObjC/CoreData/JavaScript/React application that runs on your Mac, and a C#/MSSQL/Orleans server that runs in Azure. Oh, and a little bit of glue written in Python running on AWS lambda. Yes, it's truly an unholy alliance.
What compels someone to write a net new application (from scratch with no legacy DB) that uses MSSQL?
In my book it's in front of only DB2 and Oracle on the "Will not use unless you're already using it, migration is impossible, and you're going to have to seriously pay me to deal with this" list.
What compels someone to write a net new application (from scratch with no legacy DB) that uses MSSQL?
In my book it's in front of only DB2 and Oracle on the "Will not use unless you're already using it, migration is impossible, and you're going to have to seriously pay me to deal with this" list.
We can agree to disagree, but the tooling has definitely saved me enough time to be worth it. That and realistically, no matter the DB chosen, you either use DB specific features or leave performance (often substantial) on the table.
> We can agree to disagree, but the tooling has definitely saved me enough time to be worth it.
What specifically are you referring to (regarding tooling)? Do you mean running it on Azure as a managed service that auto scales, programming tools/frameworks like LINQ, or client side GUI tools?
From an automation perspective not having a decent CLI for MSSQL to facilitate scripting makes it a pain from day one.
What specifically are you referring to (regarding tooling)? Do you mean running it on Azure as a managed service that auto scales, programming tools/frameworks like LINQ, or client side GUI tools?
From an automation perspective not having a decent CLI for MSSQL to facilitate scripting makes it a pain from day one.
SSMS is pretty great, especially for digging into query plans and deadlock graphs. Same for SQL Server Profiler.
We use Database projects in Visual Studio, so all our schema, stored procedures, and other scripts are in version control. We can compile them (additional validation) into dacpac packages, and script updates and deployment to local instances and Azure with sqlpackage and sqlcmd.
We use Database projects in Visual Studio, so all our schema, stored procedures, and other scripts are in version control. We can compile them (additional validation) into dacpac packages, and script updates and deployment to local instances and Azure with sqlpackage and sqlcmd.
The one real downside here is that you're tying your users to Windows. If you had a more "pluggable" db layer, they could use the platform of their choice.
That said, the code is in C# as well (and not .NET core, from what I saw), so they're pretty tied to Windows anyway, which is awkward since this is a macOS app.
That said, the code is in C# as well (and not .NET core, from what I saw), so they're pretty tied to Windows anyway, which is awkward since this is a macOS app.
You mean back-end developers right?
Because users are not tied to Windows, as they do not need to install the server side of the app...
Yes, I meant the backend. Apparently I misread the part where this is a SaaS product, I thought you could host the backend.
Care to expand what makes MYSQL so bad?
MSSQL = Microsoft SQL Server : https://en.wikipedia.org/wiki/Microsoft_SQL_Server
MySQL = https://en.wikipedia.org/wiki/MySQL
MySQL = https://en.wikipedia.org/wiki/MySQL
OP mentions MSSQL (Microsoft SQL Server), not MySQL.
Nice I use Bee which supports GitHub and JIRA.
http://www.neat.io/bee/index.html
Unfortunately this application supports only GitHub issues.
http://www.neat.io/bee/index.html
Unfortunately this application supports only GitHub issues.
Looks really lovely, would be great to see GitLab integration, I'm seeing a lot of people move from Github Enterprise to GitLab CE/EE which (IMO) is a lot better to work with.
Note: Not actually native, it's apparently a weird hybrid JavaScript thing rather than a Cocoa app. At least it's not just a wrapper around a WebView.
And if that weren't enough, it has some weird server component that's not Github's own API server. That means I won't touch it, because who knows what it's doing or sending…
And if that weren't enough, it has some weird server component that's not Github's own API server. That means I won't touch it, because who knows what it's doing or sending…
I'd say it's as native as Mail.app, which also renders HTML content, and relies on a remote server.
> relies on a remote server.
That isn't really a fair comparison when eschaton says
> it has some weird server component that's not Github's own API server.
The remote servers that Mail.app communicates that are... the email providers. As far as I'm aware, when I use Mail.app with Fastmail, Apple doesn't send all my Fastmail email through their servers. Mail.app talks directly to Fastmail.
A mail client which works like Ship 2.0 would be Nylas[0][1].
For anyone who wants a bug tracker for GitHub Issues, JIIRA, or FogBugz which communicates directly with their issue tracking server[2] someone mentioned Bee[3] further down.
[0]:https://nylas.com [1]:https://nylas.com/cloud [2]:http://www.neat.io/bee/security.html [3]:http://www.neat.io/bee/index.html
That isn't really a fair comparison when eschaton says
> it has some weird server component that's not Github's own API server.
The remote servers that Mail.app communicates that are... the email providers. As far as I'm aware, when I use Mail.app with Fastmail, Apple doesn't send all my Fastmail email through their servers. Mail.app talks directly to Fastmail.
A mail client which works like Ship 2.0 would be Nylas[0][1].
For anyone who wants a bug tracker for GitHub Issues, JIIRA, or FogBugz which communicates directly with their issue tracking server[2] someone mentioned Bee[3] further down.
[0]:https://nylas.com [1]:https://nylas.com/cloud [2]:http://www.neat.io/bee/security.html [3]:http://www.neat.io/bee/index.html
We actually released a version of Nylas Mail last week that communicated directly with your email provider. (Plus it's free!) More details here: https://blog.nylas.com/nylas-mail-is-now-free-8350d6a1044d
(I work at Nylas.)
(I work at Nylas.)
If only this would support PRs / code review with revisions ... !
We're working on something that I think is really good for PRs and code review. It's part way done, and already I think it's a big improvement in usability over the web based interface on github.com. But, in the interest of shipping Ship, we had to cut it from this 2.0 release.
(btw, I'm James, I wrote the client side stuff in Ship)
(btw, I'm James, I wrote the client side stuff in Ship)
I'd be a lot more curious about it if it handled Pull Requests. (Can't find anything in the screenshots or docs to indicate that it does.) The biggest pain point I've seen with GitHub's current UI is that it's hard to track PRs as they evolve over time - old revisions and comments are often hidden away, with no way to indicate what's been resolved and what hasn't.
Though to be honest, I'd be skeptical even if it supported that. I imagine finding enough open source people who will pay $9 a month for a wrapper around a free tool is a challenging business model, and I'd hate to become reliant on it only to find it's been sunsetted due to the cost model.
Best of luck to the team! I don't mean to be pessimistic, just aware of the realities of the developer tools market.
Though to be honest, I'd be skeptical even if it supported that. I imagine finding enough open source people who will pay $9 a month for a wrapper around a free tool is a challenging business model, and I'd hate to become reliant on it only to find it's been sunsetted due to the cost model.
Best of luck to the team! I don't mean to be pessimistic, just aware of the realities of the developer tools market.
> I imagine finding enough open source people who will pay $9
Actually, we intend for Ship to always be free for (truly) open source. Public repos will always work, even after the trial expires.
Actually, we intend for Ship to always be free for (truly) open source. Public repos will always work, even after the trial expires.
no one else seemed to point this out, but your name is really clever :-). 'Real Artists' for the company name and the product 'Ship', as in 'Real Artists Ship', makes me think back to not too long ago when Mr Jobs was still ...
Hint: Jira support might sell fast too (if you're looking for a second platform to support). All the people I've know who had to use it hated it (myself included), especially the UI.
Hm. I love Jira. I am the admin of my projects though, and get to actively work to make things simple for my team.
I use Github email notifications to keep on top of issues. GH lets you use different email addresses for each organization you belong to, and then you can use an email filter rule to separate issue traffic from the rest of your inbox. Admittedly far less powerful than this desktop app, but also simple, free, and native (via my native mail app). It handles a lot of my needs.
Given all the 3rd-party integrations available to the web interface (ZenHub, Harvest, to... Grammarly even), what's the point of having a native MacOS-only interface? It seems limiting / backwards to have native applications when there's already a universal web interface.
Are there features that the web interface doesn't have?
Are there features that the web interface doesn't have?
Right now we have some search and charting features that GitHub's web interface doesn't. We also hope to do a much better job with PRs (diff view especially).
The big win for us right now (and hopefully other teams) is the ability to view issues from multiple repositories all together. So if you have an organization wide "1.0" milestone, you can actually view all the issues in that milestone from all repos at once. You can also use custom queries to group things however you like across all your repos.
The big win for us right now (and hopefully other teams) is the ability to view issues from multiple repositories all together. So if you have an organization wide "1.0" milestone, you can actually view all the issues in that milestone from all repos at once. You can also use custom queries to group things however you like across all your repos.
It's probably faster, easier on the battery, and seems to follow the macOS UI guidelines.
Hopefully not too late, I'm wondering why do you use AWS lambda for?
To be honest, we wanted to play with it, and it was really easy to prototype the OAuth code (and keep our OAuth client secret out of the client) before we had the server deployed.
Now, since it works great, there's been no need to replace it.
Now, since it works great, there's been no need to replace it.
How does it compare to the official Github app: https://desktop.github.com/
It allows full interaction with GitHub Issues. The official application (I believe) only supports limited interaction with PRs.
For a new user, they may have no idea that this is a 30 day trial until they download and run the app, and I don't think that there is pricing information on the website anywhere. Not necessary to have any of this, just some feedback :)
Not really, their pricing is pretty clear. It's free for public repos and paying for private ones.
Yep - it's a 30 day free trial. After that it's $9/month. Like GitHub, we're also offering a plan for organizations that want to provide Ship to their whole team.
Our pricing page goes into more detail -- https://www.realartists.com/pricing.html
You're right, though - we should mention the free trial part on the front page. Thanks for the feedback and for trying it out!
Our pricing page goes into more detail -- https://www.realartists.com/pricing.html
You're right, though - we should mention the free trial part on the front page. Thanks for the feedback and for trying it out!
How do you charge a subscription for a downloadable, native app? Does the app stop working if I stop payments?
If you cancel or your trial expires, Ship keeps working but it only works with your public repos. The intention is that Ship is always free for open source.
The client proxies through their servers, so they probably just break your connection.
Just ask Autodesk and Adobe, it's all they do anymore
Fantastic work! Thank you for sharing. Do you guys see pressure from commercial users to offer one-time payment instead of subscriptions?
Thanks! We think the subscription model is the best fit for our product. While Ship is a native Mac app, it also relies on a backend service so we have ongoing costs to cover there.
Also, with subscriptions we don't have to play the upgrade game with our customers. We can release features as they're ready instead of holding them all back so we can justify a $50 upgrade for version 3.0.
That said, we would certainly accomodate companies that find it easier to pay annually. And, if we end up doing an enterprise, on-premise version, that may have a different pricing structure.
Also, with subscriptions we don't have to play the upgrade game with our customers. We can release features as they're ready instead of holding them all back so we can justify a $50 upgrade for version 3.0.
That said, we would certainly accomodate companies that find it easier to pay annually. And, if we end up doing an enterprise, on-premise version, that may have a different pricing structure.
Why did you develop just for OSX and would you consider supporting other platforms (Linux!) in future?
Well, we had to start somewhere, and macOS is what our team knows best. If there's enough interest, we'd love to support other platforms (including Linux).
If you have decoupled your application logic from the UI, you might wanna look into Qt/QML. Opens up support for a lot of platforms, and you can have a native-looking GUI for both Windows and Linux using the exact same codebase without "ifdeffing".
Just curious, could you link an application using Qt/QML with a native-looking Windows GUI?
Native-"looking" = Looks and feels like nothing native. Always use the best UI for each platform, which is the native UI stack.
Qt maps its widgets to native ones. As long as you pay the same attention to detail as required when you're accessing the Win32 API directly, you're going to be able to get the same results.
And as I mentioned in the other comment, QML makes it fairly easy to make UWP/Metro-style apps.
And as I mentioned in the other comment, QML makes it fairly easy to make UWP/Metro-style apps.
Again, do you have a link to one of those applications? Every time I have come across one, they look decently on Linux, but far from it under macOS, for example.
Like previous post @LeoNatan25 wrote, they looked and feel nothing like native.
Like previous post @LeoNatan25 wrote, they looked and feel nothing like native.
As I mentioned in the other comment, most people simply don't care about making it native outside of their own platform, but Qt won't get in your way if that's what you want; you have access to the native widgets, it is up to you to make it look the part.
It's easy to make it look native, but in my experience as a user of these usually-ported-from-Linux apps, the difference in responsiveness can be noticeable.
You just made me realize Microsoft's inconsistency makes it rather hard to say an app looks "native" in it. Visual Studio, Edge, Office, Explorer... look nothing alike.
In any case... Qt does map its widgets to the Win32 ones, it's not just a crude imitation. Apps like OBS, Wireshark, VLC and KeePassX get close to a native appearance, it's just that nobody seems to give a shit about going the extra mile to make an app look native in Windows.
There's this if you wanna see how you can get a Qt app to feel right on every platform: http://www.slideshare.net/qtbynokia/how-to-make-your-qt-app-...
Also, UWP style applications seem fairly easy to make with QML if, again, you give a shit.
In any case... Qt does map its widgets to the Win32 ones, it's not just a crude imitation. Apps like OBS, Wireshark, VLC and KeePassX get close to a native appearance, it's just that nobody seems to give a shit about going the extra mile to make an app look native in Windows.
There's this if you wanna see how you can get a Qt app to feel right on every platform: http://www.slideshare.net/qtbynokia/how-to-make-your-qt-app-...
Also, UWP style applications seem fairly easy to make with QML if, again, you give a shit.
Very nice, but $9/month to use?
If we're not yet there, the goal is to get to the point Ship is worth at least $9/mo. Are there any features you'd like to see?
I just tried the app and I think the typography of the issue list makes it hard to look at for me. Also, I doubt that the app is useful to me. What kinds of teams is it aimed at?
Without intending any snark, here's a guide to getting upvoted rather than downvoted for a comment like this:
"I think the typography of the issue list makes it hard to look at for me, because ________(insert constructive criticism here)________"
"I doubt that the app is useful to me, because ________(insert thoughtful feedback here)________"
I'm sure both the authors of the app and the HN readership at large would be more receptive to such a post.
"I think the typography of the issue list makes it hard to look at for me, because ________(insert constructive criticism here)________"
"I doubt that the app is useful to me, because ________(insert thoughtful feedback here)________"
I'm sure both the authors of the app and the HN readership at large would be more receptive to such a post.
Couple questions:
* I'm assuming you are using the actual end user's token for auth, so at least you have the 5000 requests per user per hour?
* It sounds like the Ship server has a lot of (potentially private) user data sitting around to keep things fast. What sort of security do you have in place to prevent data leaks or malicious access?
[1] - https://developer.github.com/v3/#rate-limiting