Windows GUI/Client

[André Pereira]

Hi everyone, I'd like to start the discussion for the Windows GUI implementation.

Not sure how many Windows users are in the clearskies project, but I would like to discuss some fundamental architecture choices before we delve into design.

Since Windows XP is now officially not supported, I don't think we should bend over in order to provide support for it. However, if we can easily do it, for example, lowering the .Net target version with no loss of functionality, we should.

What framework to create the GUI in? Here are the options I see:

- Base .Net : awesome framework, easy to do, widespread deployment. Can be implemented in C++ or C#. Lower versions of .Net ensure wider compatibility.

- MFC : old school C++ base Windows framework, near total compatibility across all versions of Windows. I personally have some experience with this framework. However it's design and inner working is dated will probably be deprecated in a few more generations.

- WPF/XAML : same as .Net, but already marked for death, so avoid.

- Silverlight : also marked for death, avoid.

- QT : open source framework, is a tad tricky to develop and more tricky to deploy a production version (I've tried and failed so far :p). May be difficult to maintain a consistent look with the more modern versions of Windows, but that's up for debate and more knowledgeable people.

That's what I see as options for now, please feel free to correct anything I'm mistaken on.

As for my choice of framework, I'm divided between base .Net and QT, don't have enough experience with QT but using an open-source framework is more in-line with an open-source project, I believe :)

[Dmitry Yakimenko]

With QT you also get cross-platform portability for free.

> --
> You received this message because you are subscribed to the Google Groups
> "ClearSkies Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clearskies-de...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[André Pereira]

Oh my, what blunder to forget to include that important information. You are right of course, this way some elements/widgets/code will be reusable in other GUI implementations.

I guess I should brush up on the QT skills, unless someone has another suggestion.

You received this message because you are subscribed to a topic in the Google Groups "ClearSkies Dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clearskies-dev/frBUJGHNnKg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clearskies-de...@googlegroups.com.

[Pedro Larroy]

I think py + qt should make things easy...   How is that for windows?

Pedro.

[André Pereira]

Py ?

[Shish]

> I'd like to start the discussion for the Windows GUI implementation.

There's already a finished* Windows (and Linux / OSX) GUI implementation, using wxWidgets for a native look on all platforms.

https://github.com/shish/clearskies-gui

The pipeline for building stand-alone .exe's for each platform is already set up too - I just haven't done that because it seems silly to package an easily-deployed GUI when the daemon doesn't exist yet :P

* "Finished" = "Has feature parity with the daemon" -- it will of course become un-finished when the daemon moves forwards and adds features, at which point the GUI should soon catch up and become finished again.

    -- Shish

[André Pereira]

I was unaware of such GUI, I'll try it.

However, I still think that it's better to try to use more specialized tools for a GUI, you don't want to have "that program" that's really stands out in a bad way, because of it's generalized origin. Not saying that is the case, I've yet to run the GUI on Windows, trying it now.

For example, TDesktop has a very nice, lightweight and modern GUI based on QT, I am hoping to achieve something in the same spirit.

[Shish]

However, I still think that it's better to try to use more specialized tools for a GUI, you don't want to have "that program" that's really stands out in a bad way, because of it's generalized origin. Not saying that is the case, I've yet to run the GUI on Windows, trying it now.

It's a systray icon with a menu - I struggle to imagine how such a simple thing could possibly require substantial platform-specific design changes :S

(Though I will admit it's been years since I read the OSX and Gnome HIGs, so I would gladly be corrected)

    -- Shish

[André Pereira]

Ah, that clears up things a bit. As a user from Windows land, that's definitely not enough. You need a windowed program gui do add shared, change preferences, get folder sync codes, etc.. Pretty much what BTsync has: and remember, they're our reference.

The good news is, that's where I want to come in :D

--

[Shish]

Ah, that clears up things a bit. As a user from Windows land, that's definitely not enough. You need a windowed program gui do add shared, get folder sync codes, etc.. Pretty much what BTsync has: and remember, they're our reference.

It already does those things... from the systray menu :P

Click icon -> "Add Share" -> pops up an OS-native folder picker

Click icon -> Go to the submenu for the share -> "Get sync code" -> pops up an OS-native dialog box with the code ready for copy & pasting

etc

>  change preferences,

It does pop up a separate window for that, and it's a fairly un-polished window at the moment -- but given that the daemon doesn't actually support changing preferences, I figure it's worth waiting for that before finalising the design. Also the layout for that window is ~20 lines of code, so even if you want the preferences window to be very different for different platforms, an "if" statement seems more efficient than writing a whole new app~

    -- Shish

[Steven Jewel]

On 05/14/2014 06:01 PM, Shish wrote:
> The pipeline for building stand-alone .exe's for each platform is
> already set up too - I just haven't done that because it seems silly to
> package an easily-deployed GUI when the daemon doesn't exist yet :P

Would it be possible to have it deploy the clearskies-ruby version right
now? I've heard that it works on Windows as long as you have the mingw
gnutls.dll present.

I think an alpha release will go a long way to attract more developers
to the project. The C++ daemon should be a drop-in replacement for the
ruby daemon.

Steven

[Shish]

I'm afraid I don't know anything about Ruby, let alone how one would deploy a Ruby app on windows >_<  I can take a look, but if anyone already knows how to do it, help would be appreciated~

    -- Shish

[Steven Jewel]

For now, why not just have them install ruby separately from
http://rubyinstaller.org. Early adopters would almost certainly be
willing to do that, and since we'd want to switch to the C++
implementation once it's ready, there's no sense in spending much time
on getting a super smooth installation procedure.

Steven