From: Andy Little (andy_at_[hidden])
Date: 2005-10-02 13:32:57
"Reece Dunn" <msclrhd_at_[hidden]> wrote in message
> Andy Little wrote:
>> "Reece Dunn" <msclrhd_at_[hidden]> wrote
>>>Andy Little wrote:
>>>>"Reece Dunn" <msclrhd_at_[hidden]> wrote
>> discovered this while reading the VFC documentation. It works fine.
> I am aware of this, but was wondering several things:
> * main() will create a console window as well as the GUI window :(
If you use the linker flag /SUBSYSTEM:WINDOWS instead of /SUBSYSTEM:console ,
it doesnt put up a console window.
FWIW with these settings args in:
int main(int argc,char* argv)
are valid :-)
FWIW Heres my linker settings
/OUT:"Debug/ReeceGui.exe" /INCREMENTAL /NOLOGO
/DEBUG /PDB:"Debug/ReeceGui.pdb" /SUBSYSTEM:WINDOWS /ENTRY:"mainCRTStartup"
/MACHINE:X86 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib
advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
>> FWIW I am thinking of working on your Boost.Gui. One essential difference I
>> would like to make is to try to use the same types on each platform, so for
>> example window sizes would all be in either integers or floats. Ideally they
>> should be templated on each type. What do you thinlk?
> Feel free to modify it as you want :) I have been very busy with work
> and other things, and working on Boost.GUI isn't a high priority for me
> at the moment.
Shame I dont think I'll get much done in the near future either:-( .. What I
really need is to get it running on Linux/Unix and Mac I
>> I might go further and add units (maybe defaulting to pixels)
>> typedef gui::rect<px,int> rect 1;
>> typedef gui::rect<pc,double> rect 2;
>> typedef gui:rect<mm,int> rect 3;
> That looks great :)!
I'd better get own with it then... ;-)
>> IMO from experience this is very powerful and makes coding much easier.
>> Alternatively / as well it might be good to set the transform ( units and
>> ,Wheres (0,0), is +Y up or down, etc ) per window.
> Interesting. You could have a windows transform and a mac transform,
> aliasing that to OS transform.
Thats it! so it defaults to the same settings on each platform. Up is always up
etc.. and you can set a Text (y goes down etc) or Graphics mode.
>> BTW On the issue of size and point ; The problem with operations specified is
>> that assuming:
>> point p1,p2,p3
>> operations such as:
>> point result_point = (p1 +p2 +p3)/3;
>> are legal mathematical constructs ( whereas (p1+p2)/3 isnt of course). Thats
>> Id prefer to go with an entity called vect which stands in for both size and
>> point. (You could make point safe with some runtime overhead I guess)
> I would prefer vector over an abbreviation.
hmm .. Ok, I guess users can change it if they wish. Anyway you seem to
approve in principle ?
I currently use a namespace called two_d e.g two_d::vector<..> .
>>>I agree that the library should be designed on the abstract level, but it
>>>should also be possible to pass a rectangle object to GetClientRect (or the
>>>equivalent in Mac, PalmOS, etc.) without having to write a lot of
>>>platform-dependant code yourself.
>> Ok but because you will inevitably be using the platform specific API , this
>> will usually be easy to achieve.
>>>That is, I want it to be easy to interact with Win32, XWindows or Mac code
>>>/in a way that is simple for the user/.
>> Maybe as a plugin.?
> What I don't want to do is:
> gui::vector pt;
> NSPoint ptNative;
> CallSomePointFunction( &ptNative );
> pt = convert_vector( ptNative );
> gui::vector pt;
> CallSomePointFunction( pt.native());
> I suppose I could write my own extension to allow:
> gui::vector pt;
> CallSomePointFunction( native_point( pt ));
Ok.. I guess the idea is that it should work with existing code?(See below about
incorporating it into C++ standard)
>> As far as compile time entities is concerned I think they could be very
>> Might even be possible to use this for resource scripts...
> These look great.
> I am willing to bet that most commercial applications that target WinNT
> and above are built using the Unicode versions of the API. Saying that
> they must use the ansi variants instead would make some, if not most, of
> the companies reluctant to switch to Boost.GUI or the standard C++ GUI.
I'm looking in terms of overtaking the competition...erhh ..hmm gradually ;-)
My first target audience for this would be C++ newcomers.
> Also, applications that interact with COM will send and receive BSTR
> strings that are always wide. These applications will most likely be
> built in Unicode to allow the BSTR strings to be passed to the Win32 API
> without conversions.
Ok... but is this actually the GUIs responsibility? Cant system calls be used
without a GUI .?
(Ok They are generally bundled in). However the standard doesnt understand the
concept of interprocess communication( or does it?) . If possible I would like
to keep the thing as lightweight as possible The goal is a minmal GUI that can
be incorporated in the standard for "basic GUI functionality". Providing a
rigorous specification for even that would be a huge amount of work. I guess
this is why I'm not getting too worried about os specifics except to hide
them.. I think they would be 'implementation defined" in the standard.
> Having the string rendering as part of the graphics module is
> interesting (indeed, the Windows GDI and I assume XWindows et. al. have
> this as part of the graphics sub-system). There should be the concept of
> a font. At least it should specify font face (e.g. "Courier New") and
> size (e.g. font_size< pt >( 12 )).
Yes. There are a large range of fonts about to take inspiration from!
Anyway this would be part of the graphics sub-system (Though default font is
bound up with L&F of course).
> Or an easier option would be to use templates like are dome with the
> string types:
> template< typename CharT >
> struct basic_window
> void set_title( const std::basic_string< CharT > & title );
> Thus, you won't need to use a specific string representation and you get
> the same semantics on every platform defined that you like :)
Thats sounds good. Thats whad I like !
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk