eiffel-mas-discuss — Mailing list for general discussion of MAS issues

Re: [MAS-discuss] Features missing from mas

[Jim C. <jt...@di...>]

Pawel -

Some good suggestions.  Thanks for sending them.

I'll respond to a few of them, below.

> Hi all,
> 
> Responding to Jim's call: here is my list of issues I have collected for MAS
> server.
> I did not have time to edit it, so it may be rather harsh or obscure at
> points, but
> I decided to post it anyway rather than waiting until I may have time to
> polish it.
> 
> Pawel Konieczny
> 
> 
> 
> My wish list (some points are strong wishes :-):
> 
> *  Use a new environment variable MAS_DATADIR to indicate where data files
> remain.  In such case, read in all files in that directory (in addition
> to files specified in command line).
> 
> *  Give alternative to all environment variables: MAS_CONFIG
> This variable should be a path to a mas configuration file.  All other
> settings (like directories, mailer, options, etc.) should be read in
> from the config file.

Do you think it be better to replace the old behavior with this scheme, or to
allow both?

> 
> *  Change the port parameter from 'NNN to '-i NNNN' and make it optional.
> This will allow for starting interactive mas sessions without allocation
> of TCP port. -i will remove ambiguity at command line (what is a port,
> what is a data file)

Well, the port number already is optional - If no port is specified, the
server will not listen for client connections; it will just function as a
command-line tool (unless -b is also specified, in which case it will do
nothing!).  But I think you want to allow a case where a number might be a
file name rather than a port number; it probably makes sense to use a flag
to allow this, but -i is taken; -p is too, but perhaps -port would work.
(FYI, more than one port number can be specified and the server will listen
on all of them.)

> 
> *  Disable the option of ^E to exit the server through the socket
> connection:
> This is insecure.  Instead of this, make mas stoppable by receiving a

You're right, the ^E method should be removed.
> signal:
> TERM is my preference.  Mas should exit _cleanly_ in such case.

The Linux version of the server already terminates if you use 'kill' to send
it a signal; I believe TERM will terminate it cleanly, except that it
prints an ugly and probably unecessary OS signal report.  However, I think
another method is also needed that will work on both Linux and Windows.
I think the server needs to accept a request from a trusted client (via a
socket connection) for termination.

> 
> *  MAS does not see new data files in the data directory.  If this is
> not easy to add, use the reception of signal HUP to re-read data.

Yes, allowing this, somehow, is on the to-do list.  Alternatives that come
to mind, in addition to your signal suggestions are: accept a client
request to reread new data (both new data for known symbols and to add to
the symbol list); periodically re-read (or re-request) the data (this only
applies to reading new data for known symbols) [e.g., every 5 minutes, for
intraday data].  Both would probably be good.  Comments?

> 
> *  When I define a new indicator, I have to restart mas in order to use it.
> It should be usable immediately. (strong wish)

I believe this has been added in mas 1.6.6g - at least, I just tested it
and it worked for me.

> 
> *  Get rid of the old-fashioned lock file when editing indicators - mas
> daemon
> may have rw access to the indicators file, but not to the directory this
> file resides in.

I'm not clear on what you're proposing here as a replacement for the
lock-file behavior.

> 
> *  Option -b should detach mas into background automatically.
> 
> *  For each signaled event provide the underlying market data too.
> Preferably with the context marked data, i.e. from the previous and next
> period.  This will allow for easy writing scripts that analyze the
> hypothetical gain/loss when operating on a given market analyzer.
> 
> *  Allow for selecting individual stocks for a specific market analyzer.
> Currently, only the analyzing period can be set.  Because stocks differ
> in nature, a market analyzer good for one does not need to be good for
> another. (or should I say: event registrant?) (strong wish)
> 
> * Allow for repeated dates in input files (last data overrides previous)
> 
> * Make mas able to serve multiple clients.  Currently, when one client
> connects to MAS, all other connections (including GUI clients) hang. This
> could be done by either spawning a child process or making MAS
> multi-threaded.

By multiple clients, I assume you mean command-line clients (macl), since
it can serve more than one GUI at the same time because of its
request-response design.  But, yes, starting up a macl will hog the server
until the macl exits.  Multithreading may be the best answer, but this will
take some work.

> 
> * Provide an option to specify the data file format (instead of the old
> -o). For instance, -m ohlcv means that data file (or database) contains open
> high low close volume; -m ohlcvi the same + open interest; -m lhc means only
> low
> high close (in this order). For the database it would be preferable to be
> able to define it directly in mas_dbrc.
> 
> * Make MAS able to process data without high/low and/or volume.  Some
> tradables come without detailed data.  Use -m c for only close data.

The above two are good suggestions.  Note that the server can already tell by
itself if a tradable has an open-interest field or not.  But it won't work
to determine if the data has, e.g., a high field; that will need to be
specified, as you suggest.  I've considered allowing only date(/time)
and close.  This would allow use of time-series data other than
market-related data - e.g., it could be used for statistical analysis.
However, eliminating the date field would probably require very large
changes to the design and I'm not sure the benefit would outweigh the
work involved; other than that, allowing other missing fields would be
useful and doable, although still not a simple change.

> 
> * Allow for database queries returning no rows or rows with some NULL
> data. Do not report errors on that. Filter out indicators that
> cannot be used in such case. (strong wish)
> 
> * Let define the MAS_MAILED during the client session (overruling
> the default for that client session). Save it along with defined market
> event registrants during the session. (strong wish)
> 
> * Do not require read/write file permissions on read-only client
> operation (like viewing market data or indicators data)

I just tried a chmod 444 on the indicators_persist and generators_persist
files and started the server and was able to view and edit the indicators
and generators (but not able to save the changes, of course).  Is there
something you're not able to do that I'm missing?

> 

Note that one thing I always need to keep in mind when deciding on new
features is that mas needs to work equally well on both Windows and Linux,
which means avoiding behavior that makes sense on one OS but not on the
other.


Jim

Re: [MAS-discuss] Features missing from mas

[Pawel K. <kon...@zo...>]

Hi all,

Responding to Jim's call: here is my list of issues I have collected for MAS
server.
I did not have time to edit it, so it may be rather harsh or obscure at
points, but
I decided to post it anyway rather than waiting until I may have time to
polish it.

Pawel Konieczny



My wish list (some points are strong wishes :-):

*  Use a new environment variable MAS_DATADIR to indicate where data files
remain.  In such case, read in all files in that directory (in addition
to files specified in command line).

*  Give alternative to all environment variables: MAS_CONFIG
This variable should be a path to a mas configuration file.  All other
settings (like directories, mailer, options, etc.) should be read in
from the config file.

*  Change the port parameter from 'NNN to '-i NNNN' and make it optional.
This will allow for starting interactive mas sessions without allocation
of TCP port. -i will remove ambiguity at command line (what is a port,
what is a data file)

*  Disable the option of ^E to exit the server through the socket
connection:
This is insecure.  Instead of this, make mas stoppable by receiving a
signal:
TERM is my preference.  Mas should exit _cleanly_ in such case.

*  MAS does not see new data files in the data directory.  If this is
not easy to add, use the reception of signal HUP to re-read data.

*  When I define a new indicator, I have to restart mas in order to use it.
It should be usable immediately. (strong wish)

*  Get rid of the old-fashioned lock file when editing indicators - mas
daemon
may have rw access to the indicators file, but not to the directory this
file resides in.

*  Option -b should detach mas into background automatically.

*  For each signaled event provide the underlying market data too.
Preferably with the context marked data, i.e. from the previous and next
period.  This will allow for easy writing scripts that analyze the
hypothetical gain/loss when operating on a given market analyzer.

*  Allow for selecting individual stocks for a specific market analyzer.
Currently, only the analyzing period can be set.  Because stocks differ
in nature, a market analyzer good for one does not need to be good for
another. (or should I say: event registrant?) (strong wish)

* Allow for repeated dates in input files (last data overrides previous)

* Make mas able to serve multiple clients.  Currently, when one client
connects to MAS, all other connections (including GUI clients) hang. This
could be done by either spawning a child process or making MAS
multi-threaded.

* Provide an option to specify the data file format (instead of the old
-o). For instance, -m ohlcv means that data file (or database) contains open
high low close volume; -m ohlcvi the same + open interest; -m lhc means only
low
high close (in this order). For the database it would be preferable to be
able to define it directly in mas_dbrc.

* Make MAS able to process data without high/low and/or volume.  Some
tradables come without detailed data.  Use -m c for only close data.

* Allow for database queries returning no rows or rows with some NULL
data. Do not report errors on that. Filter out indicators that
cannot be used in such case. (strong wish)

* Let define the MAS_MAILED during the client session (overruling
the default for that client session). Save it along with defined market
event registrants during the session. (strong wish)

* Do not require read/write file permissions on read-only client
operation (like viewing market data or indicators data)

[MAS-discuss] Features missing from mas

[Jim C. <jt...@di...>]

Hi, MAS-discuss members.

I'm not sure if the timing is right for this request - I suppose I'll know
based on what kind of response I get; but I'd like to initiate a discussion
of features that are needed in MAS.  The MAS team (which currently consists
of Pedro Pla and I) is trying to determine what features should be added in
the next several months, and getting your feedback on this would be
extremely helpful.

For those of you who have used commercial packages, such as Tradestation or
Metastock, I'd like to hear what features you've seen in those packages
that are missing from MAS.  But I'd also like to hear from people who have
been thinking something like: "Man, this would be a really nice package if
only it just did this ...".

I know that many of you have submitted feature suggestions and requests
already, but I think it would be helpful to have this discussion here,
since a discussion can give some context - allow people to clarify issues,
talk about the best way to do things, etc.; plus this will make all of
these issues available to me in one place so that I can enter them into a
database.

Please try to keep the same subject line (with "Re: " is fine, of course)
to make it easy to locate emails from this discussion.  (If you send a
suggestion, I'd prefer it if you send it to this list, but if you prefer,
you can send it directly to me.)

Thanks!


Jim Cochrane

[MAS-discuss] Another data-services question - real-time data feed

[Jim C. <jt...@di...>]

Reading the questions about services that provide data, I'm reminded that I
haven't been able to find an answer to a related question I've had for
quite a while (though I admit I haven't searched particularly hard for the
answer).  Does anyone know of a real-time data-feed service that is
platform-independent (not Windows-dependent) - that is, uses a protocol
(e.g., socket-based) that can be accessed from Linux, Windows, Solaris,
etc.?  This type of service would probably be made available via an API.
I'm not concerned about cost at this point.  This is more of a research
question.


Thanks!
Jim Cochrane

Re: [MAS-discuss] EOD Data for ASX

[David C. <cro...@in...>]

Paul Tazzyman wrote:
>
> There are two sources that I know of:-
> 
> www.weblink.com.au - they email the data to you and charge
> about $AUD35 per month, Details are available from:-
> 
> WebLink Pty Ltd
> Tel. (02) 9495 8400
> Fax (02) 9495 8401
> Lo...@we...
> www.weblink.com.au

Great thanks. I did come across them with Google. Not quite what
i want, but it is closer.

> If you run linux there is a simple perl script you can use which uses
> Lynx to get the data from tradingroom.com.au. This data isn't updated
> till about 45 minutes before start of trading the next day but the
> quality is excellent. Best thing its free !!
> 
> If you need more info on the perl stuff - let me know !!

Yes please. This is sounding more like what i need. Perhaps they even
have a for-fee service that provides the data earlier.

--David

[MAS-discuss] Re: MAS Software - MySQL DB

[Jim C. <jt...@di...>]

Hi Oscar.

> Hi,
> 
> I have recently installed and tested MAS on Linux RedHat 7.3
> using flat text files as DB.
> 
> I wish to switch to using MySQL as DB. So far I have a working
> MySQL and unixODBC. I am setting up the DB for MAS and
> from the sysadmin docs it is mentioned that there are Postgress
> scripts for doing so. However, I have looked and looked in the
> files but have not found them.=20
> 
> Is there any chance that I can have a copy of these scripts ?

Yes.  Several people have asked me this question.  When I read your email,
I realized it was time for me to put it in the FAQ.  Here's the answer,
copied from the FAQ
(http://eiffel-mas.sourceforge.net/support/FAQ.html#database):

The example script files for creating MAS tables reside in a file separate
from the main MAS installation file. You will find them in the scripts
archive file in the download section - either scripts{relnum}.tar.gz or
scripts{relnum}.zip -, where {relnum} stands for the release number -
e.g., 1.6.5. (The scripts files for the latest release, 1.6.5 - as of
June 2003 - are scripts1.6.5.tar.gz and scripts1.6.5.zip.) Several people
have asked me this question, so I've concluded that I need to include
the database scripts with the main installation file. I will probably
do this for the next official (non-beta) release.

[The download URL is:
http://sourceforge.net/project/showfiles.php?group_id=6838]

> When I have successfully completed this exercise is it worth
> that I write a how-to for MySQL and post at subsciption list ?

Definitely!  This would be much appreciated - not only by me, but, I'm
sure, by future MAS users who want to do the same thing.

(I'm also sending this response to the tips and discuss lists.)

> 
> Thanks in advance.
> 
> Oscar Plameras

You're quite welcome.

Jim Cochrane

[MAS-discuss] EOD Data for ASX

[Paul T. <pta...@ya...>]

David,

There are two sources that I know of:-

www.weblink.com.au - they email the data to you and charge about $AUD35
per month, Details are available from:-

WebLink Pty Ltd
Tel. (02) 9495 8400
Fax (02) 9495 8401
Lo...@we...
www.weblink.com.au

If you run linux there is a simple perl script you can use which uses
Lynx to get the data from tradingroom.com.au. This data isn't updated
till about 45 minutes before start of trading the next day but the
quality is excellent. Best thing its free !!

If you need more info on the perl stuff - let me know !!

Regards,
Paul

Re: [MAS-discuss] re: looking for source of reliable end-of-day data

[David C. <cro...@in...>]

Ching Chew wrote:
> Hi David,
> 
> I run the website for my investment club with semi-realtime portfolio pricing
> and we use data from the Yahoo! Finance website:
> 
> http://au.finance.yahoo.com
> 
> You will notice that once you do a search (say with QAN) that you will get an
> option to download the data in a spreadsheet format. Note the URL:
> 
> http://au.finance.yahoo.com/d/quotes.csv?s=qan&m=a&f=sl1d1t1c1ohgv&e=.csv
>
> Parse the .csv output and you can get various trading details. Modifying the
> above URL and playing with the variables should give you the information about
> opening, closing, hi, low and volume that you require.
> 
> FYI our website stores these information in a database everytime a partner
> requests our portfolio value webpage.

Thanks for your help. However that is what i do already for testing
purposes. I use "quotemonster" as a local command-line script. It goes
to yahoo and gets the data each working day for a small selection of
stocks.

There are various problems. Often one or more of the OHLC prices are
missing. When there is zero trades on a stock, then even the date is
screwed up. It is a hard method for a large number of stocks. Overall 
it seems to not be reliable data. But hey, it is free.

I am also not clear whether such data sources provide "adjusted" data.
Is it just raw data - it needs to be adjusted for Corporate Actions
notified by the exchange, such as capital reconstruction including
splits and consolidations.

So i am looking for a decent managed data service. Google finds plenty
that appear to come close. However they all seem to require Windoze
client software and user actions each day.

--David

Re: [MAS-discuss] re: looking for source of reliable end-of-day data

[Jim C. <jt...@di...>]

Hi Ching.

Welcome to the MAS-discuss list!  I'm the main author of MAS.

Looks like you're in Australia.  I believe several current MAS users are
also from Australia.

> 
> Hi David,
> 
> I run the website for my investment club with semi-realtime portfolio pricing
> and we use data from the Yahoo! Finance website:
> 
> http://au.finance.yahoo.com
> 
> You will notice that once you do a search (say with QAN) that you will get an
> option to download the data in a spreadsheet format. Note the URL:
> 
> http://au.finance.yahoo.com/d/quotes.csv?s=qan&m=a&f=sl1d1t1c1ohgv&e=.csv
> 
> Parse the .csv output and you can get various trading details. Modifying the
> above URL and playing with the variables should give you the information abou
t
> opening, closing, hi, low and volume that you require.
> 
> FYI our website stores these information in a database everytime a partner
> requests our portfolio value webpage.
> 
> General:
> This is my first post and can I say that I am very excited to find an Eiffel
> program in my interest area. Studied Eiffel at uni and have not had a chance 
to
> see it in action yet - perhaps I need to go out more. =)

Glad to hear you like Eiffel.  It's an under-appreciated language :-)

> 
> Are there any plans to port this over as a web-app?

It's already been done, in the sense of converting the charting GUI to
an applet and writing a servlet to mediate between the applet and the
MAS server.  (There's more that could be done, of course.)  I haven't
released it yet, since I haven't yet figured out the licensing, etc.,
for it.


Jim Cochrane

[MAS-discuss] re: looking for source of reliable end-of-day data

[Ching C. <ch...@ct...>]

Hi David,

I run the website for my investment club with semi-realtime portfolio pricing
and we use data from the Yahoo! Finance website:

http://au.finance.yahoo.com

You will notice that once you do a search (say with QAN) that you will get an
option to download the data in a spreadsheet format. Note the URL:

http://au.finance.yahoo.com/d/quotes.csv?s=qan&m=a&f=sl1d1t1c1ohgv&e=.csv

Parse the .csv output and you can get various trading details. Modifying the
above URL and playing with the variables should give you the information about
opening, closing, hi, low and volume that you require.

FYI our website stores these information in a database everytime a partner
requests our portfolio value webpage.

General:
This is my first post and can I say that I am very excited to find an Eiffel
program in my interest area. Studied Eiffel at uni and have not had a chance to
see it in action yet - perhaps I need to go out more. =)

Are there any plans to port this over as a web-app?

cheers!
Ching



---------------------------

Ching Chew
cTernet Pty Ltd
http://www.cternet.com.au
ACN: 102 391 364
ABN: 76 102 391 364
Tel: 0403 312 449

Electronic Teaching Administrator (ETA)
http://www.cternet.com.au/products/eta.php

e-Folio Career Management Software
http://www.cternet.com.au/products/efolio.php

[MAS-discuss] MAS for Windows has been added to the 1.6.6g beta release

[Jim C. <jt...@di...>]

For those interested in the Windows version of MAS, I have added the file
mas-windows1.6.6g.zip, which includes the new mas.exe and the new
indicators_persist and generators_persist files.  It can be downloaded from
the "files" page at:

http://sourceforge.net/project/showfiles.php?group_id=6838

[MAS-discuss] Signal generation: file logging bug has been fixed

[Jim C. <jt...@di...>]

I have just discovered that the bug that caused a core dump when
using the file logging options for trading signal generation is fixed.
This may especially be good news to Windows users who have struggled
unsuccessfully to get event (signal) logging working with the the awkward
"fake_mailer.bat" script.  The facility is also available to Linux users,
of course - for those who wish to log their signals to a file instead
of have them sent as email.  (See below for a description of how to use
file logging.)

I should mention that I tested this on Windows with the new mas.exe
(1.6.6g) and on Linux with 1.6.6g and the old 1.6.5 release.  Since all
tests were successful, I think there's a very good chance that Windows
users will also find that it works with 1.6.5.

However, as many of you know, a couple tests cannot ensure that a problem
does not exist.  I think the chances that the bug remains are small, since
the previous behavior was quite consistent: generate a core dump.  If
anyone tries out file logging with 1.6.5 or later and still runs into
problems, please let me know.

Why did I not discover this earlier?  Simply because I had done nothing to
fix the bug and hadn't thought to test it before - too much to do.  Chances
are 99.9% that the bug was in the ISE library class I was using and it has
been fixed there.

To use file logging for trading signals: From the MAS command line enter
'r' for Edit event registrants, then 'a' for Add registrants, then 'l' for
Log file.  Type a file name for the log file.  Then choose the event types
you want.  Then type '-' for Previous, then 's' for Save changes.  The next
time you run a market analysis, this "registrant" will be used and the
generated signals will be written to the log file whose name you specified.


Jim

Re: [MAS-discuss] Proposed major changes to the charting GUI

[Jim C. <jt...@di...>]

I'd like to thank everyone who participated in the discussion about
improving the MAS charting GUI.  There were some very good suggestions and
advice that should help Pedro and I to produce a GUI that is a lot better
than the existing one.  (Although Pedro should get most of the credit for
the results, since he will be doing most of the GUI work.)


Thanks.
Jim Cochrane

Re: [MAS-discuss] MDI GUI going going gone

[Pawel K. <kon...@zo...>]

> Unless there is convincingly strong evidence that MDI is
> needed I think it can all be done and look slick without it, what do you
> all think? Should I abandon MDI completely for the look I propose here?
>
> Pedro
>

I think all ideas you proposed in this post are very good.  Now the
challenge to implement them.

Pawel

[MAS-discuss] looking for source of reliable end-of-day data

[David C. <cro...@in...>]

Does anyone know where i can get proper and reliable
end-of-day data (Open, High, Low, Close, Volume) for
the Australian stocks ASX?

I expect an Internet-based server that holds fully-adjusted
and reliable data. An automated client at my end would
download it, rather than send it to me via email,
i.e. no manual steps. I expect to send a request specifying
a time period and receive a comma-separated values file for all
securities and indices. I would then make a little shell-script
to manage it locally and store it so that mas server can use it.

And no windows-based client software.

Of course i do expect to pay for such a service.

Google found me a list at:
http://www.blazetech.com.au/blaze_chart/Blaze_Chart_Data_providers.html
but none of those seemed to suit.

--David

Re: [MAS-discuss] Proposed major changes to the charting GUI

[David C. <cro...@in...>]

Jim Cochrane wrote:
<snip/>
> Do others agree that being able to do either or both of these would
> be very useful?

Everything that has been discussed is totally useful.

<snip/>
> 
> That's an important question.  In people's opinion, what are the better
> TA/charting programs in terms of GUI design and what paradigm do they use?

The one that i like is Qtstalker ... http://qtstalker.sf.net/
As i said in another thread, i intend to use both it and magc.

It has similar mode to the MAS magc. It has the ability to have
different groups of stocks within which you navigate next/previous.

--David

Re: [MAS-discuss] Proposed major changes to the charting GUI

[David C. <cro...@in...>]

Pedro Pla wrote:
> CW Johnson wrote:
> 
> >I currently use MAS on Windows XP, along with our other services.
> >I LOVE the ability
> >to have 2 separate windows, and put them on 2 of the 4 screens on my
> >workstation.
> >While I agree that MDI has a nicer layout, I think that having the
> >ability to spread out MAS onto different desktops ranks high on my list.
> 
> Ok, thanks for that, I wouldn't have thought of it since I only use one 
> monitor currently (no space on my desk at home for more ;). I think your 
> point is very valid and many traders will be using two screens due to 
> the inherit advantages of having them, so having independant windows for 
> the screens will definately be important.

I have six virtual desktops and have separate magc windows on two
or three of them. Each magc window occupies the full screen.

However surely those are the concern of the operating system's
window manager. As long as magc can open separate windows.

All the ideas that have been discussed are excellent.

--David

[MAS-discuss] MDI GUI going going gone

[Pedro P. <ped...@ho...>]

Hi,

After the recent discussions and suggestions brought to my attention on 
this channel I've decided  to completely move away from an MDI interface 
towards a tabbed & split window inteface which would allow studies in a 
tab and each study to contain several chats in split windows, this would 
allow better scaling which I think is important for charts, as well as a 
cleaner interface than MDI.
There will be a left vertical menu (a la open office left menu or 
outlook second left menu, not the iconed one), with several "tabbed" 
sections where you can select indicators, symbols, etc.
There will be several toolbars one for cursor type (crosshair or 
normal), another for the type of chart drawing to do (Trend lines, 
Fibonacci Price retracments, etc), there will also be a color selector 
somewhere so you can drag a color onto an object (indicator, trend line, 
etc) to set the color. All of these except the color selection will also 
be available via a menu bar.
When you open a chart you will be able to open it in either A) a new 
window, B) a new tab, & C) a new section of the selected tab. If you 
want to change the symbol on a chart you will just drag a new one to it 
from the symbol indicator, that will also be the way to change the 
indicators. Unless there is convincingly strong evidence that MDI is 
needed I think it can all be done and look slick without it, what do you 
all think? Should I abandon MDI completely for the look I propose here?

Pedro

Re: [MAS-discuss] Proposed major changes to the charting GUI

[Pedro P. <ped...@ho...>]

CW Johnson wrote:

>I currently use MAS on Windows XP, along with our other services. I LOVE
>the ability
>to have 2 separate windows, and put them on 2 of the 4 screens on my
>workstation.
>While I agree that MDI has a nicer layout, I think that having the
>ability to spread
>out MAS onto different desktops ranks high on my list.
>
Ok, thanks for that, I wouldn't have thought of it since I only use one 
monitor currently (no space on my desk at home for more ;). I think your 
point is very valid and many traders will be using two screens due to 
the inherit advantages of having them, so having independant windows for 
the screens will definately be important.

Pedro

>
>
>Just my 0.02
>
>-cedrick
>
>-----Original Message-----
>From: eif...@li...
>[mailto:eif...@li...] On Behalf Of Jim
>Cochrane
>Sent: Monday, May 26, 2003 10:11 PM
>To: eif...@li...
>Subject: [MAS-discuss] Proposed major changes to the charting GUI
>
>
>Pedro Pla has been enthusiastically making changes to the GUI that I
>believe will add vast improvements to the functionality of MAS.  These
>improvements include the addition of trend lines and fibonacci lines.
>
>One thing he's considering is change the GUI to work as a multi-document
>interface (MDI).  Although I've not used metatock or tradestation, this
>is apparently the format used by those programs, so future TA users
>(especially Windows users) are probably going to expect it.  I know
>there aren't many (perhaps none) Windows users subscribing to this list.
>Nevertheless, I'd like to get feedback from you fellow Linux users about
>MDI, as well as from any Windows users who are on the list.  I'd like to
>hear what you think of MDI, its advantages and disadvantages.
>
>I think it would be best if people post this discussion to this list.
>Please make sure "charting GUI" appears in the subject line so that
>those who aren't interested can filter these emails out.
>
>Below is a listing of advantages and disadvantages of MDI that Pedro and
>I have been able to think of.  Please use this as a starting point for
>your comments.
>
>Being a non-MDI user, my concern is that an MDI will remove some
>flexibility. For example, I think it could be harder (or at least more
>awkward) to position charting windows in different locations on the
>screen than without MDI. (E.g., in some cases you'd first have to expand
>the main window before you can use the entire screen.  And I don't
>believe you would be able to temporarily position a charting window
>mostly off-screen.)  Also, I don't think you could move one of your
>charting windows to a different desktop like you can with the current
>version.
>
>Advantages of MDI include a nicer graphic layout that is common to all 
>windows since there can be one menu bar and one set of tool bars that 
>affect all of the windows in the MDI desktop which will create a cleaner
>
>control interface; it also allows easier drag and drop of components 
>between the MDI desktop. The new GUI will be very object oriented and 
>the way to change an indicator on a chart will simply be to drag it on 
>or off the chart, and the way to change the charted symbol will be to 
>drag a new one onto the chart, this will give greater ease of use to 
>both the experienced user and the new joe user.
>
>Another advantage of MDI is the way you can organize your chart windows 
>side by side so that you can create studies based on them and then save 
>the layout as a study. Example, I want to create a study on the OEX (S&P
>
>100) so I create one daily chart, and one weekly chart, that way I can 
>see the more intermediate trend and the global trend side by side, I can
>
>also then compare them with two more charts of lets say QQQ and see 
>whether the intermediate and global trends are similar, whether one 
>leads another, etc. After I have this all laid out with my trend lines 
>drawn I can then save it as a study (ie: oex vs qqq), and next time I 
>want to look at it I just load the study and it's all laid out like I
>want. There is always the possibility of maximizing a window in the mdi,
>or we 
>can even consider creating a new mdi window when a user requests "study 
>in new window" just the same, the user could request "chart in new 
>window to detach the chart to a new window.
>
>
>Thanks.
>Jim
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: ObjectStore.
>If flattening out C++ or Java code to make your application fit in a
>relational database is painful, don't do it! Check out ObjectStore. Now
>part of Progress Software. http://www.objectstore.net/sourceforge
>_______________________________________________
>Eiffel-mas-discuss mailing list Eif...@li...
>https://lists.sourceforge.net/lists/listinfo/eiffel-mas-discuss
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: ObjectStore.
>If flattening out C++ or Java code to make your application fit in a
>relational database is painful, don't do it! Check out ObjectStore.
>Now part of Progress Software. http://www.objectstore.net/sourceforge
>_______________________________________________
>Eiffel-mas-discuss mailing list
>Eif...@li...
>https://lists.sourceforge.net/lists/listinfo/eiffel-mas-discuss
>
>  
>

Re: [MAS-discuss] Proposed major changes to the charting GUI

[Pedro P. <ped...@ho...>]

Jim Cochrane wrote:

>>Pawel Konieczny wrote:
>>
>>    
>>
>>>Hi Jim and Pedro,
>>>
>>>I am a "Windows user" and MDI is not what I expected.  I know that it is
>>>...
>>>
>>>The state of the art currently is to use panned and tabbed windows and
>>>(detachable) toolbars, like in Outlook, Outlook Express, or even in
>>>Developer Studio.  Tabs allow for quick switching between predefined layouts
>>>(with possibly its own content), while resizable and draggable panes allow
>>>for quick and efficient layout change.  Detachable toolbars and menus allow
>>>for trade off between how much of screen space is left for main display vs.
>>>how much information may be hidden by overlapping window.
>>>
>>>      
>>>
>>Ok, that sounds like something to look at, and all these opinions are 
>>very valuable, my question is if a tabbed system as such were 
>>implemented how would side by side chart comparisons work? Any ideas? 
>>    
>>
>
>I just thought of a couple possibilities - are these doable?  Allow the
>windows to be independent, but provide the option of "hooking" two
>windows (or more) together, either end-to-end or bottom-to-top (i.e.,
>vertically or horizontally).  Once they're hooked together, they can
>be moved, resized, etc. as one window.  Also, I think either or both of
>these possibilities would be quite useful and appealing:
>
>Possibility 1: The user clicks a button to make the current window he's
>working with "transparent".  Then he moves that window so that it covers
>another window.  He then clicks a button that resizes the transparent
>window so that it is the same size and aligned exactly over the other
>window.  Since the first window is transparent, the user can see both
>its contents (price chart, indicators, etc.) and the covered window's
>contents and can thus compare the two charts.
>
Ok in Java that is pretty inviable, however what you are asking for here 
can be done by allowing two symbols to be shown on the same chart, 
somthing that I hope to implement eventually.

>
>Possibility 2: The user moves window A so that it covers window B (if it's
>smaller it only partially covers B).  The user then clicks some kind of
>"merge windows" button and the two windows are magically merged into one
>window.  The result is that the chart for symbol x from window A and the
>chart for symbol y from window B both appear in the newly merged window.
>
Ok, that can be done easier without MDI, it seems that MDI is really 
being ruled out, and I'm starting to see why with what I'm making in the 
GUI, the interface isn't as clean and easy to use as it should.. I'm 
thinking of a lot of other ways to do it without mdi, using tabbed 
windows for studies, split windows for multiple side by side charts, 
that would solve the scaling problem Pawel pointed out, and would 
probably have a much better visual effect.

>
>Do others agree that being able to do either or both of these would be very
>useful?
>
I think what you outlined is really the way we should go, I think MDI is 
as Pawel well said, outdated, and their are many better ways to layout 
our application.

>
>Pedro, are the above 2 possibilities implementable?
>
Yes they are, although slightly different in the way of creating them, 
but the same visual effect I believe.

>
>  
>
>>All feedback is greatly appreciated, I thought of doing it with MDI 
>>since most of the TA programs I have seen use it, are there newer ones 
>>that don't? Which are they? I would like to see them.
>>    
>>
>
>That's an important question.  In people's opinion, what are the better
>TA/charting programs in terms of GUI design and what paradigm do they use?
>
>Jim
>
>  
>
>>Thanks
>>
>>Pedro
>>
>>    
>>
>>>And finally: I do believe that MDI is better than the current UI design, so
>>>it will be an improvement anyway.
>>>
>>>Pawel
>>>      
>>>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: ObjectStore.
>If flattening out C++ or Java code to make your application fit in a
>relational database is painful, don't do it! Check out ObjectStore.
>Now part of Progress Software. http://www.objectstore.net/sourceforge
>_______________________________________________
>Eiffel-mas-discuss mailing list
>Eif...@li...
>https://lists.sourceforge.net/lists/listinfo/eiffel-mas-discuss
>
>  
>

Re: [MAS-discuss] Proposed major changes to the charting GUI

[Pawel K. <kon...@zo...>]

> Possibility 1: The user clicks a button to make the current window he's
> working with "transparent".  Then he moves that window so that it covers
> another window.  He then clicks a button that resizes the transparent
> window so that it is the same size and aligned exactly over the other
> window.  Since the first window is transparent, the user can see both
> its contents (price chart, indicators, etc.) and the covered window's
> contents and can thus compare the two charts.
>
> Possibility 2: The user moves window A so that it covers window B (if it's
> smaller it only partially covers B).  The user then clicks some kind of
> "merge windows" button and the two windows are magically merged into one
> window.  The result is that the chart for symbol x from window A and the
> chart for symbol y from window B both appear in the newly merged window.

Very original ideas; I have never seen them but they look very interesting.
If we forget animations, they are doable.

Pawel

Re: [MAS-discuss] Proposed major changes to the charting GUI

[Pawel K. <kon...@zo...>]

  Pedro : =3D=3D
  I agree that it has many flaws when dealing with a lot of =
applications, however it does present some advantages as outlined in the =
previous email, would you think the advantages outweigh the =
disadvantages? Their could also be a sort of "hybrid" interface where =
you could open new windows or windows in the mdi, would that help in =
something? At least give more choice to the user?
  =3D=3D=3D=3D=3D=3D=3D=3D

The ideas I presented are for SDI, not multiple application windows. =20
  Pedro : =3D=3D
  Ok, that sounds like something to look at, and all these opinions are =
very valuable, my question is if a tabbed system as such were =
implemented how would side by side chart comparisons work? Any ideas? =
All feedback is greatly appreciated, I thought of doing it with MDI =
since most of the TA programs I have seen use it, are there newer ones =
that don't? Which are they? I would like to see them.
  =3D=3D=3D=3D=3D=3D=3D=3D
Indeed, MDI is very popular.  I guess it is because in times they were =
created, MDI was promoted by many development tools.  But look at =
VisionExpert, a program from Belgium, written in Delphi, demo version =
downloadable from http://www.visionexpert.be/. It gives a good example =
of a very usable program based on SDI/tabs/panes.  Don't take this as an =
example of an ideal TA program; it is actually very weak in manual chart =
analysing (drawing trendlines etc.) - use it as a source if ideas.

An example of a good program for maual charting (but weak in overal =
design) is a Dutch program written in Java, available at =
http://www.chartnet.nl/.=20

Pawel

Disclaimer: I do not advertise any of the programs above - there are =
many good (better) TA programs out there.

Re: [MAS-discuss] Proposed major changes to the charting GUI

[Jim C. <jt...@di...>]

> Pawel Konieczny wrote:
> 
> >Hi Jim and Pedro,
> >
> >I am a "Windows user" and MDI is not what I expected.  I know that it is
> >...
> >
> >The state of the art currently is to use panned and tabbed windows and
> >(detachable) toolbars, like in Outlook, Outlook Express, or even in
> >Developer Studio.  Tabs allow for quick switching between predefined layouts
> >(with possibly its own content), while resizable and draggable panes allow
> >for quick and efficient layout change.  Detachable toolbars and menus allow
> >for trade off between how much of screen space is left for main display vs.
> >how much information may be hidden by overlapping window.
> >
> Ok, that sounds like something to look at, and all these opinions are 
> very valuable, my question is if a tabbed system as such were 
> implemented how would side by side chart comparisons work? Any ideas? 

I just thought of a couple possibilities - are these doable?  Allow the
windows to be independent, but provide the option of "hooking" two
windows (or more) together, either end-to-end or bottom-to-top (i.e.,
vertically or horizontally).  Once they're hooked together, they can
be moved, resized, etc. as one window.  Also, I think either or both of
these possibilities would be quite useful and appealing:

Possibility 1: The user clicks a button to make the current window he's
working with "transparent".  Then he moves that window so that it covers
another window.  He then clicks a button that resizes the transparent
window so that it is the same size and aligned exactly over the other
window.  Since the first window is transparent, the user can see both
its contents (price chart, indicators, etc.) and the covered window's
contents and can thus compare the two charts.

Possibility 2: The user moves window A so that it covers window B (if it's
smaller it only partially covers B).  The user then clicks some kind of
"merge windows" button and the two windows are magically merged into one
window.  The result is that the chart for symbol x from window A and the
chart for symbol y from window B both appear in the newly merged window.

Do others agree that being able to do either or both of these would be very
useful?

Pedro, are the above 2 possibilities implementable?

> All feedback is greatly appreciated, I thought of doing it with MDI 
> since most of the TA programs I have seen use it, are there newer ones 
> that don't? Which are they? I would like to see them.

That's an important question.  In people's opinion, what are the better
TA/charting programs in terms of GUI design and what paradigm do they use?

Jim

> 
> Thanks
> 
> Pedro
> 
> >
> >And finally: I do believe that MDI is better than the current UI design, so
> >it will be an improvement anyway.
> >
> >Pawel

RE: [MAS-discuss] Proposed major changes to the charting GUI

[CW J. <jav...@ce...>]

I currently use MAS on Windows XP, along with our other services. I LOVE
the ability
to have 2 separate windows, and put them on 2 of the 4 screens on my
workstation.
While I agree that MDI has a nicer layout, I think that having the
ability to spread
out MAS onto different desktops ranks high on my list.


Just my 0.02

-cedrick

-----Original Message-----
From: eif...@li...
[mailto:eif...@li...] On Behalf Of Jim
Cochrane
Sent: Monday, May 26, 2003 10:11 PM
To: eif...@li...
Subject: [MAS-discuss] Proposed major changes to the charting GUI


Pedro Pla has been enthusiastically making changes to the GUI that I
believe will add vast improvements to the functionality of MAS.  These
improvements include the addition of trend lines and fibonacci lines.

One thing he's considering is change the GUI to work as a multi-document
interface (MDI).  Although I've not used metatock or tradestation, this
is apparently the format used by those programs, so future TA users
(especially Windows users) are probably going to expect it.  I know
there aren't many (perhaps none) Windows users subscribing to this list.
Nevertheless, I'd like to get feedback from you fellow Linux users about
MDI, as well as from any Windows users who are on the list.  I'd like to
hear what you think of MDI, its advantages and disadvantages.

I think it would be best if people post this discussion to this list.
Please make sure "charting GUI" appears in the subject line so that
those who aren't interested can filter these emails out.

Below is a listing of advantages and disadvantages of MDI that Pedro and
I have been able to think of.  Please use this as a starting point for
your comments.

Being a non-MDI user, my concern is that an MDI will remove some
flexibility. For example, I think it could be harder (or at least more
awkward) to position charting windows in different locations on the
screen than without MDI. (E.g., in some cases you'd first have to expand
the main window before you can use the entire screen.  And I don't
believe you would be able to temporarily position a charting window
mostly off-screen.)  Also, I don't think you could move one of your
charting windows to a different desktop like you can with the current
version.

Advantages of MDI include a nicer graphic layout that is common to all 
windows since there can be one menu bar and one set of tool bars that 
affect all of the windows in the MDI desktop which will create a cleaner

control interface; it also allows easier drag and drop of components 
between the MDI desktop. The new GUI will be very object oriented and 
the way to change an indicator on a chart will simply be to drag it on 
or off the chart, and the way to change the charted symbol will be to 
drag a new one onto the chart, this will give greater ease of use to 
both the experienced user and the new joe user.

Another advantage of MDI is the way you can organize your chart windows 
side by side so that you can create studies based on them and then save 
the layout as a study. Example, I want to create a study on the OEX (S&P

100) so I create one daily chart, and one weekly chart, that way I can 
see the more intermediate trend and the global trend side by side, I can

also then compare them with two more charts of lets say QQQ and see 
whether the intermediate and global trends are similar, whether one 
leads another, etc. After I have this all laid out with my trend lines 
drawn I can then save it as a study (ie: oex vs qqq), and next time I 
want to look at it I just load the study and it's all laid out like I
want. There is always the possibility of maximizing a window in the mdi,
or we 
can even consider creating a new mdi window when a user requests "study 
in new window" just the same, the user could request "chart in new 
window to detach the chart to a new window.


Thanks.
Jim


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore. Now
part of Progress Software. http://www.objectstore.net/sourceforge
_______________________________________________
Eiffel-mas-discuss mailing list Eif...@li...
https://lists.sourceforge.net/lists/listinfo/eiffel-mas-discuss

Re: [MAS-discuss] Proposed major changes to the charting GUI

[Pedro P. <ped...@ho...>]

Pawel Konieczny wrote:

>Hi Jim and Pedro,
>
>I am a "Windows user" and MDI is not what I expected.  I know that it is
>used in some TA programs, notably the older ones.  However, MDI, introduced
>by Microsoft many years ago, is flawed from the usability point of view, and
>even Microsoft is now abandoning it - look at Word2000.  Originally Word was
>one of the first serious applications using MDI, but currently, when I open
>several Word documents, they all appear in different Word instances.  The
>main problem with MDI are overlapping windows: since all child windows are
>independent, resizing one does not automatically resize other and leads to a
>chaos. Closing a window does not utilize the free screen estate for other
>windows and opening a new window will hide some information content already
>on screen. Smaller problem is that too much space is wasted on (resizable)
>window borders.
>
I agree that it has many flaws when dealing with a lot of applications, 
however it does present some advantages as outlined in the previous 
email, would you think the advantages outweigh the disadvantages? Their 
could also be a sort of "hybrid" interface where you could open new 
windows or windows in the mdi, would that help in something? At least 
give more choice to the user?

>
>The state of the art currently is to use panned and tabbed windows and
>(detachable) toolbars, like in Outlook, Outlook Express, or even in
>Developer Studio.  Tabs allow for quick switching between predefined layouts
>(with possibly its own content), while resizable and draggable panes allow
>for quick and efficient layout change.  Detachable toolbars and menus allow
>for trade off between how much of screen space is left for main display vs.
>how much information may be hidden by overlapping window.
>
Ok, that sounds like something to look at, and all these opinions are 
very valuable, my question is if a tabbed system as such were 
implemented how would side by side chart comparisons work? Any ideas? 
All feedback is greatly appreciated, I thought of doing it with MDI 
since most of the TA programs I have seen use it, are there newer ones 
that don't? Which are they? I would like to see them.

Thanks

Pedro

>
>And finally: I do believe that MDI is better than the current UI design, so
>it will be an improvement anyway.
>
>Pawel
>
>
>
>----- Original Message -----
>From: "Jim Cochrane" <jt...@di...>
>To: <eif...@li...>
>Sent: 2003 May 27 05:11
>Subject: [MAS-discuss] Proposed major changes to the charting GUI
>
>
>  
>
>>Pedro Pla has been enthusiastically making changes to the GUI that I
>>    
>>
>believe
>  
>
>>will add vast improvements to the functionality of MAS.  These
>>    
>>
>improvements
>  
>
>>include the addition of trend lines and fibonacci lines.
>>
>>One thing he's considering is change the GUI to work as a multi-document
>>interface (MDI).  Although I've not used metatock or tradestation, this is
>>apparently the format used by those programs, so future TA users
>>    
>>
>(especially
>  
>
>>Windows users) are probably going to expect it.  I know there aren't many
>>(perhaps none) Windows users subscribing to this list.  Nevertheless, I'd
>>like to get feedback from you fellow Linux users about MDI, as well as
>>from any Windows users who are on the list.  I'd like to hear what you
>>think of MDI, its advantages and disadvantages.
>>
>>I think it would be best if people post this discussion to this list.
>>Please make sure "charting GUI" appears in the subject line so that
>>those who aren't interested can filter these emails out.
>>
>>Below is a listing of advantages and disadvantages of MDI that Pedro and I
>>have been able to think of.  Please use this as a starting point for your
>>comments.
>>
>>Being a non-MDI user, my concern is that an MDI will remove some
>>    
>>
>flexibility.
>  
>
>>For example, I think it could be harder (or at least more awkward) to
>>    
>>
>position
>  
>
>>charting windows in different locations on the screen than without MDI.
>>(E.g., in some cases you'd first have to expand the main window before you
>>can use the entire screen.  And I don't believe you would be able to
>>temporarily position a charting window mostly off-screen.)  Also, I don't
>>think you could move one of your charting windows to a different desktop
>>like you can with the current version.
>>
>>Advantages of MDI include a nicer graphic layout that is common to all
>>windows since there can be one menu bar and one set of tool bars that
>>affect all of the windows in the MDI desktop which will create a cleaner
>>control interface; it also allows easier drag and drop of components
>>between the MDI desktop. The new GUI will be very object oriented and
>>the way to change an indicator on a chart will simply be to drag it on
>>or off the chart, and the way to change the charted symbol will be to
>>drag a new one onto the chart, this will give greater ease of use to
>>both the experienced user and the new joe user.
>>
>>Another advantage of MDI is the way you can organize your chart windows
>>side by side so that you can create studies based on them and then save
>>the layout as a study. Example, I want to create a study on the OEX (S&P
>>100) so I create one daily chart, and one weekly chart, that way I can
>>see the more intermediate trend and the global trend side by side, I can
>>also then compare them with two more charts of lets say QQQ and see
>>whether the intermediate and global trends are similar, whether one
>>leads another, etc. After I have this all laid out with my trend lines
>>drawn I can then save it as a study (ie: oex vs qqq), and next time I
>>want to look at it I just load the study and it's all laid out like I
>>    
>>
>want.
>  
>
>>There is always the possibility of maximizing a window in the mdi, or we
>>can even consider creating a new mdi window when a user requests "study
>>in new window" just the same, the user could request "chart in new
>>window to detach the chart to a new window.
>>
>>
>>Thanks.
>>Jim
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: ObjectStore.
>>If flattening out C++ or Java code to make your application fit in a
>>relational database is painful, don't do it! Check out ObjectStore.
>>Now part of Progress Software. http://www.objectstore.net/sourceforge
>>_______________________________________________
>>Eiffel-mas-discuss mailing list
>>Eif...@li...
>>https://lists.sourceforge.net/lists/listinfo/eiffel-mas-discuss
>>    
>>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: ObjectStore.
>If flattening out C++ or Java code to make your application fit in a
>relational database is painful, don't do it! Check out ObjectStore.
>Now part of Progress Software. http://www.objectstore.net/sourceforge
>_______________________________________________
>Eiffel-mas-discuss mailing list
>Eif...@li...
>https://lists.sourceforge.net/lists/listinfo/eiffel-mas-discuss
>
>  
>