GUI for OS X

[doob]

I'm thinking of starting to work on a GUI for OS X again. Would you prefer that as a separate project like airdcnano or should I use the ardic++ repository and contribute the changes?

[Night]

Im pretty much fine with either way, but i would prefer some cross platform gui library so the whole AirDC could be moved to using it instead of having to update multiple versions on things added/changed, rewriting the gui totally is a big job anyway.

If its AirDC for OS X only i think better would be to use own repository like airdcnano.

[doob]

Im pretty much fine with either way, but i would prefer some cross platform gui library so the whole AirDC could be moved to using it instead of having to update multiple versions on things added/changed, rewriting the gui totally is a big job anyway.

I'm mostly only interested in OS X. Personally I haven't seen a cross platform GUI that is good enough on OS X. They always look alien one way or another, but that can of course be the application and not the actual GUI library.

If its AirDC for OS X only i think better would be to use own repository like airdcnano.

Any interested in having that in the existing github namespace or should I just use my own?

[maksis]

I've been working on a Javascript UI (+API) that could be used on multiple platforms and embedded devices. It won't look more native than other web-based applications (such as Spotify) but being able to run the app on device such as NAS server and accessing it from various other devices feels like a huge benefit (at least in my usage scenario).

[doob]

I've been working on a Javascript UI (+API) that could be used on multiple platforms and embedded devices. It won't look more native than other web-based applications (such as Spotify) but being able to run the app on device such as NAS server and accessing it from various other devices feels like a huge benefit (at least in my usage scenario).

That's a cool idea but I don't have a use for it in practice. I recall that Shakespeer was built like this (a daemon and a GUI) but I never ran the daemon on any other computer than the one I run the GUI on.

What I do think would be useful is a command line interface. Not like airdcnano but a batch program what would perform some operation and exit when completed. But that could fairly easily be accomplished by having the GUI application act like the daemon and connect to it using Unix sockets (or similar). This is how applications like TextMate and Sublime work when invoking them from the command line.

Regardless if the application is a single GUI application or a daemon and a GUI front end I would still like to have a native GUI for OS X and be able to run the daemon/server on OS X.

Hopefully if the separation between the model and the views (as in the MVC pattern) is good enough it should be fairly simple to modify the GUI to receive the data from the model layer from a daemon or server. I would need to have a clear separation anyway because AirDC++ is written in C++ and I would like to write the GUI in Swift.

[doob]

BTW, what's the status of the API? Is it something that can already be used?

[maksis]

BTW, what's the status of the API? Is it something that can already be used?

It's a JSON API that can be used via HTTP calls or for bidirectional communication via Websockets. Basic functionality is there already (auth, routing, event subscribers, list controller) but there arent't many calls implemented yet. Would that be useful for you?

[doob]

It's a JSON API that can be used via HTTP calls or for bidirectional communication via Websockets. Basic functionality is there already (auth, routing, event subscribers, list controller) but there arent't many calls implemented yet. Would that be useful for you?

No, I was more thinking if an API like this will be added anyway I could build the GUI on top of that. But I had hoped for something more lightweight than JSON for transferring. Or will there be something different when using web sockets?

If this was added I was hoping I could use Unix sockets for communication. But perhaps the same information could be sent as would be sent using web sockets.

But don't add or rush anything just for me. I think it would be easier for me not use this.

[maksis]

But I had hoped for something more lightweight than JSON for transferring.

This doesn't seem relevant for me as there won't be much data being transferred between the API and the UI. The list view component is fully virtual: it will only fetch data for rows that are visible at the moment and only data for updated column properties is being pushed to the UI. Even the Windows GUI has list and tree views virtualized in similar manner. You'd be in trouble otherwise when browsing a list with 500k items in a single directory or if you have 100k bundles queued. Transferring chat messages via JSON shouldn't cause significant resource usage either.

[doob]

Ah, ok, I see.

[maksis]

I've commited an initial version of the API to https://github.com/airdcpp/airdcpp-webapi

[doob]

I've commited an initial version of the API to https://github.com/airdcpp/airdcpp-webapi

It's pretty cool. Hopefully I'll have time to look at this at some point . BTW, shouldn't the AirDC++ core be added as a submodule?

Great that you split the cross-platform core from the rest of the code.

[maksis]

BTW, shouldn't the AirDC++ core be added as a submodule?

My idea is that the API is just one library that is required by the actual application project. I'm also going to use a separate repository for the web UI, so the main app (or apps) can then require each of them (core, API, web UI).

[doob]

I see. I was expecting that the API requires the core to work and therefor should be induced as a dependency. I assuming that "API" is the actual server that an application is connecting to.