On Wed, 29 Oct 2008, Szak�ts Viktor wrote: Hi Viktor and Pritpal,
>> I think Pritpal is trying to get into the scheme of "inherits from GTWVT >> to avoid duplicated code". > IMO this way it's done the wrong way. > For one, GTWVG has - from the beginning - > lots of duplicated GTWVT code, which is > still there. And Pritpal wants to remove it and simply inherit from GTWVT. IMHO it's good idea. Now the proposed extensions. We already have in GUI based GTs extensions which are not portable to other GTs. F.e. you added font resizing to GTWVT when user changes the window size (just like in GTALLEG). I like this feature but it's not portable to other GTs like GTTRM/GTCRS/GTSLN which have to accept that terminal changes its state without our control and can be resized by user what usually changes number of rows and columns so it's compatible with previous GTWVT behavior. There are some differences between GTs and we cannot hide all of them. In this case we talk about three features: - passing style to console window so it can be tuned to look and behave like other OS windows - bounding console window with other group of visible objects or desktops - setting initial possition for new console window. For me all of them are important just like important is font selection or color palette setting. In some situations even much more important because without them it may not be possible to create console window at all in some environments, f.e. in XWindow I can display console window on different desktops, different XServers and different computers. If it will not be possible to control some of such local to given GT features then it may not possible to use some GTs. F.e. I can have application which works on remote server without any display adapter as daemon (service in Windows technology). On request this application can create console window using GTXWC on my local computer giving some functionality like online configuration. If I do not introduce some new features to GTXWC which are not available in MS-Windows/DOS world then GTXWC will not be usable for me. I will have to make copy of GTXWC for my own use to change only few lines just like now GTWVG is copy of GTWVT with some extensions. It's not good situation with also introduce other problems. Extensions will appear locally and will be strictly bound with given GTs so code using them will not be portable ot other GTs and platforms. We should try to reduce such situation and if possible try to define some interface which can be implemented also in other GTs which have similar possibilities. If sth cannot be well emulated by all GTs then we should add option which will allow to check GT capabilities from user code. F.e. just like now we can call hb_gtInfo(HB_GTI_ISGRPAHIC) to check if GT can operate on pixels or only on characters. It does not mean that we need all extensions in core code but we should allow to write 3-rd party / contrib code which can use core GTs as base. In this case I see why Pritpal wants to introduce such extensions and seems that the final results will be very interesting. Anyhow I do not like that they are such strictly hardcoded to be MS-Windows API parameters. In such case we will have similar set of parameters but incompatible also for XWindow and maybe MacOSX or OS2 if someone create GUI GTs for these systems. So I suggest to define what elements we want to set and use definitions with some meaning defined by us which then can be used with other GTs. So now we need: HB_GTI_WINDOWSTYLE We should also define our own styles HB_GTI_WS_* instead of using MS-Win constant values if we want to make this feature portable to other platforms. Please also do not start with whole list of all possible styles in some platform but use only these ones which are necessary and will be implemented and fully supported. As I can see we already have: HB_GTI_SETPOS_XY / HB_GTI_SETPOS_ROWCOL Looks that it's enough for basic window positioning. Pritpal, what else do you need to control window creation? I think that predefined window classes can be covered by our styles (and it will be good for portability) but maybe I'm wrong. BTW we can add to GTWVT thread which will redraw all existing console window asynchronously to Harbour code. In such case it will process all window messages. This will have one side effect. It will not be able to execute .prg code from message loop because it's not HVM thread. So please remember that any code which uses notifiers will not be able to benefit from such functionality which cannot be enabled for it. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
