Login Page - Create Account

Support Board


Date/Time: Sat, 23 Nov 2024 18:43:34 +0000



Future planned OS platforms for SC

View Count: 25326

[2015-11-12 05:11:18]
User35525 - Posts: 181
Dear SC engineering,

Rather than an extremely broad framework like QT, please consider a tighter C++ framework like SFML, which is extremely portable, is mature, is not so monolithic, stands on its own with few dependencies, is engineered well like SC, is actively developed, and has a friendly license.

I am presently using SC on Linux+Wine, and would really hate to see SC fracture future development by forking the Windows codebase to create an OS X version built with a completely different API. That would certainly cause major logistics headaches and maintainability issues for SC engineering to support.

Sincerely,
A concerned customer
[2015-11-12 05:32:05]
Sierra Chart Engineering - Posts: 104368
We will have a look at SFML.

For the record, this thread most likely is in response to this thread here:
Announcement: Long-Term Development Plans to Support Other Operating Systems
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service:
Sierra Chart Teton Futures Order Routing
Date Time Of Last Edit: 2016-03-26 08:39:02
[2015-11-12 05:51:43]
User35525 - Posts: 181
Thanks; see this part of the SFML FAQ about GUI packages and GUI libraries:
https://github.com/SFML/SFML/wiki/Community-FAQ#libraries
That wiki article should have listed the "SFML Projects" sub-forum:
http://en.sfml-dev.org/forums/index.php?board=10.0

You can use any OpenGL-based GUI library, even interfacing it with QT if you wanted to use QT's native widgets and dialogs, but SFML for most everything else to keep things as maintainable as possible by using QT minimally:
http://en.sfml-dev.org/forums/index.php?topic=18660.0

In addition to the main site's tutorials, these 3rd-party tutorials are a good introduction:
http://en.sfml-dev.org/forums/index.php?topic=19264.0
Date Time Of Last Edit: 2015-11-12 07:16:38
[2015-11-12 08:01:48]
ganz - Posts: 1048
SC Support

The safest thing that we might decide to do is to support Mac or Linux and not both of them.
That post has some good points.
Mac port would be the logical step for mouse operators.
But trading engines should support it as well but they don't.

Also QT5 and GTK3 have no good performance and stability states at this time.
Nothing has changed during last 20 years in this area.
At this moment RedHat has supported GTK: Gimp, Firefox, LibreOffice.
Looks like it will be the primary tool for the new crossplatform .Net Core initiative from M$.

So looks like there are no any sense to waste the time for Linux nor Mac now. :)
[2015-11-12 08:21:01]
ganz - Posts: 1048
RedHat has supported GTK: Gimp, Firefox, LibreOffice.
and GNOME3 using Wayland API of course :)

GNOME3 might be the new basic UI for Linux because a lot of old linux users have prefered it.
[2015-11-12 08:49:16]
Sierra Chart Engineering - Posts: 104368
What is the basis of this statement?:

Also QT5 and GTK3 have no good performance and stability states at this time.

Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service:
Sierra Chart Teton Futures Order Routing
[2015-11-12 09:18:26]
ganz - Posts: 1048
SC Support

It is based on Reports from devs
4ex:
the Qt 5.5.1 patch release provides close to 1.000 improvements and fixes
http://blog.qt.io/blog/2015/10/15/qt-5-5-1-released/

and on personal experience using QT5/GTK3 Apps in terms of stability, CPU usage, memory leaking and so on.
[2015-11-12 17:43:50]
User35525 - Posts: 181
I wouldn't mind SC using a simple OpenGL-based GUI library to provide dialogs and widgets, such as these:
CEGUI: http://cegui.org.uk/features
ImGui: https://github.com/ocornut/imgui
MyGui: http://mygui.info/#ui-tabs-13

Keeping it simple (SFML) and using one of these GUI toolkits would look non-native, but who cares, as long as it's stable and fast, and does what you want? It may be beneficial to keep the list of dependencies small even with the GUI framework.

QT isn't a bad solution, however, and many companies are using it in desktop apps, like Adobe, Amazon, Google, Microsoft (Skype), and others. It does seem to be very-widely adopted and constantly improving:
https://news.ycombinator.com/item?id=9793920
https://igurublog.wordpress.com/2014/01/25/gtk-fesses-up-this-aint-for-you-qt-takes-over-the-world/
Date Time Of Last Edit: 2015-11-12 17:47:29
[2015-11-12 19:40:57]
ejtrader - Posts: 688
I would like to vote for Qt5.x unless there are any show stoppers..

Thanks
[2015-11-12 20:09:30]
Sierra Chart Engineering - Posts: 104368
The basic fundamental problem is once we start using QT for windows and dialogs, the entire main application object and all of the windows and all of the dialogs all have to be converted at once. And all of the graphics code would have to be changed or at least some changes would have to be made.

This is too much work all at once.

This is the basic fundamental problem. The consequences of this are potentially so serious, that we realize at this point it is a risk that we are not willing to take. A good example of this is whenever Microsoft comes out with a new operating system, they make too much of a drastic change . Think about all of the problems that users experience. That is not something that is acceptable to us or our users.

The strategy has to be to find a way to incrementally port Sierra Chart to another operating system gradually while still maintaining the Windows version as it always has been other than incremental changes.

So we do not think the QT at this point, is a reasonable choice for a project like this. That is why, no firm decision was ever made on it.

We will look at these other GUIs mentioned in the post above. If we can start using something like that gradually to modify our existing code, that may be a good choice.


We will continue on the path, of making changes to Sierra Chart so it is less and less dependent on Microsoft classes and functions.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service:
Sierra Chart Teton Futures Order Routing
Date Time Of Last Edit: 2015-11-12 20:14:02
[2015-11-13 01:46:18]
ganz - Posts: 1048
User35525

OpenGl is deprecated.

Vulkan would be the right choice, imho.
[2015-11-13 02:02:43]
ganz - Posts: 1048
User35525

QT isn't a bad solution, however, and many companies are using it in desktop apps, like Adobe, Amazon, Google, Microsoft (Skype), and others. It does seem to be very-widely adopted and constantly improving:
Adobe is well known as linux hater
M$ just leaves skype as is. And skype is still 32 bit only app.
Google uses a bunch of libs. buttons is not the main line for it.
Amazon? :)

Who are these guys? :)

http://tirania.org/blog/archive/2012/Aug-29.html
http://tirania.org/blog/archive/2013/Mar-05.html
Date Time Of Last Edit: 2015-11-13 02:03:41
[2015-11-13 02:23:56]
ganz - Posts: 1048
SC Support

SC is the best charting and trading app I've ever seen to trade futures and Forex.

So yes, there is the thing to be careful with. :)
[2015-11-13 03:01:55]
Sierra Chart Engineering - Posts: 104368

So yes, there is the thing to be careful with. :)
Yes, we will be careful and we will certainly not jeopardize the quality and reliability of Sierra Chart.

Anyway, we discussed this today and we are going to continue the process of creating common functions and classes which encapsulate operating system level functions and GUI functions. This makes Sierra Chart better organized and easier to maintain.

In should allow us to adopt more easily another OS incrementally and using conditional compilation while still maintaining the very same Sierra Chart Windows program just like it is.

At the same time allow us to continue to make continuous new features and improvements in Sierra Chart for the general user base, without putting the Sierra Chart program on hold for many months while we attempted to adopt another OS.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service:
Sierra Chart Teton Futures Order Routing
Date Time Of Last Edit: 2015-11-13 03:02:21
[2015-11-13 03:31:23]
ganz - Posts: 1048
SC Support

That sounds smart.

It's not a good time to make a choice. Because of Linux.
[2015-11-13 03:55:27]
ganz - Posts: 1048
User35525

fyi: https://www.khronos.org/assets/uploads/developers/library/overview/vulkan-overview.pdf
[2015-11-13 05:13:33]
User35525 - Posts: 181
Hi ganz,

Thanks for the heads-up about Vulkan. I had run across that before, but didn't realize it was to be released so soon. I'm not a hardcore programmer, and have just recently started playing with graphics by compiling the nim-csfml library examples for the Nim language, which use SFML's C bindings. Nim will likely have a Vulkan API Nim wrapper later this year. All the Python guys should really checkout Nim, especially if you know C or C++. It's fast, and feels like a better C and better Python: http://nim-lang.org

IgnorantGuru just came up in Google. ;-)I'm not ready to jump ship from Linux to OS X, having just recently moved completely from Windows.

I'm just glad SC has been engineered so well it works in Wine.
Date Time Of Last Edit: 2015-11-13 05:29:01
[2015-11-13 05:43:11]
ganz - Posts: 1048
User35525

Hi, of course :)

Thanx for the info. It is interesting.

trading engines not so flex as we want it to be
so I'm stuck with lua, python and I believe in .Net Core for small/private projects in the nearest future - 1-2 years.

Saying OpenGl as deprecated I meant big players are trying to start Vulkan in order to get something cross platform, modern, fast, simple and well designed. As Wayland should be.

I see all that new API-s and cloud-based setups for big data learning as a future.

SC is the perfect app at this time, but it has no future in this frozen functionality.
Third-party modern GUI API-s is too complex and heavy to be stable, fast and predictable.
Small ones is not well supported and might be died or acquired at any time.
So I'm not an optimist about that.
[2015-11-13 07:01:05]
User35525 - Posts: 181
Speaking of Lua, Python, and Nim, I just saw wxWidgets has bindings for all three. It's smaller than QT, is cross-platform, and has native controls. A combo of SFML (main app) and wxWidgets (dialogs and widgets) could be great, but probably have the same issue as QT to SC engineering: https://www.wxwidgets.org/about/screenshots/

I like the goals of cross platform, fast, simple, and well designed.. But "modern" is a moving target. :-) If a project meets the first goals, it will build a community and stay supported/modern, until the next best thing comes along. Yes, the smaller frameworks have issues meeting all of those goals, but if they have few dependencies, and the dependencies are mature-enough, you can support it yourself if that's the best path.

I think everything is moving to the cloud too, but as much as things change, they can stay the same. Technology, and all changing landscapes, follow the path of least resistance, like water flowing downstream. As much as I disdain change, and used to feel "big data" was a fad, I think you are correct about the migration to the cloud and scaling. Even with trading, retail traders could always use more data and more-intensive backtest processing, which may lend itself to bigger cloud environments.

I'm hopeful SC can negotiate a long-term solution. By taking responsibility over both OS and graphics API, they can maybe write wrapper functions to ensure they keep porting SC as times change. I'm not looking forward to the death of the desktop, and hope Microshaft doesn't speed that along, but even now I'm writing this on a tablet, and run SC in a VPS, remotely connected to my tablet. The personal computer must stay "personal" to be individually useful, and the same goes to OS's and trading software. The world will always need solutions that offer more choice, and SC fills that niche for me.
Date Time Of Last Edit: 2015-11-13 07:18:34
[2015-11-13 07:31:10]
Sierra Chart Engineering - Posts: 104368
This looks interesting:
https://www.wxwidgets.org/about/screenshots/
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service:
Sierra Chart Teton Futures Order Routing
[2015-11-13 12:22:32]
User742717 Mike - Posts: 86
In an ideal world, everyones favorite platform is supported, sadly the more builds/fork the more problems and resources required.

Obviously, if CS main goal was multi-platform then it would be in java :D
Thankfully, it's not!

I like keeping a clean/minimalist VM (VirtualBox) and it simple and works very well!
I think most non window users expect specialised software to be mostly on windows.
http://virtualbox.org/ (free for personal use or a license is $50USD)

Being mostly a Linux user, I have no problem with CS being bear bones win32/MFC/VC++.
Unless Microsoft is changing the rules (ie app store?) then I don't get the business case for multi-platform support.

Just my thoughts.
[2015-11-13 20:12:39]
Sierra Chart Engineering - Posts: 104368
Not everyone runs Windows, so it is important that Sierra Chart supports other operating systems. It is not a priority, but it is a long-term objective that is important.

We have had a look at this:
https://www.wxwidgets.org/

Very impressed with what we see. So we are going to do some testing. This very well might be the development framework we would use.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service:
Sierra Chart Teton Futures Order Routing
[2015-12-12 18:46:15]
ganz - Posts: 1048
ejtrader
I would like to vote for Qt5.x unless there are any show stoppers.

4 exmpl: https://bugreports.qt.io/browse/QTBUG-42985

just be more pedantic to see the reality.
it is not the time to start to use it :)
[2015-12-12 21:49:31]
Sierra Chart Engineering - Posts: 104368
Regarding QT, as we have previously said it was something being considered, but there was never any definite decision until there was more consideration, there was performance testing, and until we had sufficient experience with it and understanding of it.

It is our decision that QT is not going to be used and never would be used. It would have been a disastrous mistake for ourselves and for users if we did something like that and that would never have happened. Support of another operating system will not come in 2016 but may come in 2017.

And the concept of a multi-OS development framework probably is not necessarily the right choice for Sierra Chart because we need to have complete control over the program and have direct interface with the OS for performance reasons. We would have to find the right development framework that is very lightweight and reliable, and in combination use that with direct OS interfacing for various things like network I/O and file I/O.

The WX Widgets framework/library is something we are looking at.

None of this is a simple task and is the basic reason why the support of another operating system by Sierra Chart, is not going to come for at least another year.

Also the QT bug mentioned is something we have also seen with Skype on Windows and we understand that Skype uses QT. So it is interesting you mention that bug because we noticed it about two weeks ago and it was confirmation to us of the serious danger in getting involved with these other development frameworks and why QT would never come under consideration any longer.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service:
Sierra Chart Teton Futures Order Routing
Date Time Of Last Edit: 2015-12-12 21:50:50

To post a message in this thread, you need to log in with your Sierra Chart account:

Login

Login Page - Create Account