Hello Viktor >> And transform the actual presentation to more and more graphical.
>Yes, this seems to be the same thing Pritpal >suggested last year as Multi-Window GT. Exactly except the part "graphical". My insistance was on multi-windows, graphical pard depend on the GT in question. <<< Shortly: Adding core support so that any GTs can have several independent display areas, where the actual visualization of these is GT dependent (it could be classic CUI windows inside the one main window for GTWIN/GTWVT for example, it may be distinct CUI-in-GUI windows as in GTWVW, but I may even be possible to choose between these modes at runtime, so that GTWVT can be extended to support both old-fashioned and native multi-window, but probably not both at the same time.) >>> No, if implemented along the lines I suggested, both can coexist at the same time. <<< We need to discuss how to implement it in a way to it doesn't introduce hidden extensions and doesn't break existing code on Harbour, and breaks the less code on C level and/or make transition for C level code the easiest. >>> The way I suggested, nothing breaks the third party code OR existing Clipper code. Because Przemek superb work on GT abstraction implements everything needed for Multi-Ws. <<< This means adding _new parameters to existing functions should be avoided_. >>> As I said it does not break anything and we have nothing to change in C code exept for PRG callable functions like DispOut(),DispBox() etc. <<< Instead, we may add a few new functions to switch between windows: hb_wSelect( [<nNewSelectedWnd>] ) -> nPrevSelectedWnd After such call all regular display functions will be rerouted to the selected window. Existing classes and other program parts which are supposed to keep writing to the same window (like TBrowse), should internally store the selected window at creation time, and select this whenever doing any output. >>> This is the area where I totally disagree. Xbase++ implemented it in their much propogated campaign to lure Clipper programmers but it is totally a frustration. In the modern era we need to match the current presentation protocols. For example, how will you control if the user clicks on other appln window? For every GT command you cannot match a hb_wSelect() as in m-w environment the program flow is controlled the user instead of application. <<< We will need to define which so far global GT properties should stay global and which should be converted to the per-window data. Selected color and current row/pos for example will be per-window. Good example for something to think about is DispBegin()/DispBegin(). SetCursor() is something which would stay global IMO. >>> We need not to define anything. Przemek has already done it in GT core ad is perfect. <<< Any applications not multi-window aware, will keep working as before, by doing all outputs to the "base" window. Exact specifics of the "base" window should also be discussed. >>> This is exactly what I did. If you do not pass a window handle ( an internal index number ) all outputs are routed to base window given a number 0 at the time of initialization. <<< Additionally, we should define a new set of Harbour functions to directly do output to any selected window: hb_wOpen( ... ) -> <wnd> hb_wClose( wnd ) hb_wDispOut( wnd, "Text" [, cnColor ] ) hb_wDispOutAt( wnd, 10, 10, "Text" [, cnColor ] ) hb_wSetColor( wnd [, cnColor ] ) -> <cnOldColor> hb_wSetPos( wnd, r, c ) hb_wRow( wnd ) -> r hb_wCol( wnd ) -> c hb_wBox( wnd, ... ) hb_wShadow( wnd[, nMode ] ) -> <nOldMode> hb_wMove( wnd, ... ) hb_wShow( wnd ) hb_wHide( wnd ) hb_wMaxRow( wnd ) hb_wMaxCol( wnd ) hb_wList() -> <aWnd> (list of all open windows) >>> This is where I strongly differ. All existing GT methods are capable of setting/returning values of respective window. However, hb_wList() -> <aWnd> (list of all open windows) will be an additional one. It can also go into core. <<< Maybe it would be a good idea to introduce numeric-based colors in this new API, so that we can depart from the 16/16 colors, and to make color handling easier. Specifics of this should be discussed. I'd personally stick with palette based approach, but supporting 256 (or 65535) choices for both background and foreground. So that one color would be a word or a double word (it is currently byte). >>> I ever longed for this functionality but found the solution in palette only. It will be nice to see this capability in core but for sure it will break a lot of existing code. <<< Last but not least, most C level GT API functions should be extended with a new window handle parameter. This will also mean that 3rd party GTs will have to adapted since C level compatibility will be lost. >>> C level GT API functions need not to be changed. Only PRG callable C functions need one more parameter. DispOutAt( nRow, nCol, xVariable, cColor[, hWindow ] ) DispBox( ...[, hWindow ] ) and so on. If [hWindow] is omitted, base window is the output surface. <<< Important, but natural property of the multi window GT is that all windows will be "buffered". GTs will need to be extended to render these buffers on the available output buffer (or display the separately, by using f.e. Windows API to render them). >>> This is already there. Each window has its own buffer. <<< There are a lot more to be discussed, like "modal"/"non-modal", routing inputs, how to solve everything above if we don't have a "base" window (should we support this at all in the first round), and those things which I completely forgot >>> Yes. To implement this is much easier. SUMUP: For multi-window to be a success it is important that user be able to control the flow of operations instead of program code. Regards Pritpal Bedi PS: First look executable and sources can be found at http://www.nabble.com/Multi-Window-GT---III---MemoEdit%28%29-tt14554190.html#a14554190 -- View this message in context: http://www.nabble.com/GT--Multi-platform-Messaging-Interface-tp17789933p17850687.html Sent from the Harbour - Dev mailing list archive at Nabble.com. _______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
