Your effort for harbour is Huge, very Thanks
I can't help you because not write C, but anything you need please
ask me: I try.
I think that also Pritpal have agree your idea
So is interesting see create the bed for natively windowing GTs
(like GTWVW).
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.
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.)
Do you (or anybody) see any contraindication for this idea?
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.
This means adding _new parameters to existing functions
should be avoided_.
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.
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.
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.
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)
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).
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.
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).
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
Brgds,
Viktor
-----Messaggio originale-----
Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
] Per conto di Szakáts Viktor
Inviato: domenica 15 giugno 2008 12.44
A: Harbour Project Main Developer List.
Oggetto: Re: R: [Harbour] GT- Multi-platform Messaging Interface
Yes, I'm ready to actively participate but this will be a team work.
Brgds,
Viktor
On 2008.06.15., at 12:24, Massimo Belgrano wrote:
Do you plan "add windows support in core" for upcoming release?
-----Messaggio originale-----
As a first step I would personally add (~move from CT)
window support to core. I'm for example relying on
a custom written windowing system, so I cannot use the
CT one as is. Admittedly this is a rare thing, but
having windowing capabilities in core GT would be good
for everyone I guess.
This way CT windowing could become just a thin(nish)
compatibility layer above the core implementation.
Having window support in core could create the bed
for natively windowing GTs (like GTWVW). From this
point on, the actual presentation could be changed to
more and more graphical.
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
