"Reece Dunn" <msclrhd@hotmail.com> wrote in message news:dhove2$jj9$1@sea.gmane.org...
Andy Little wrote:
"Reece Dunn" <msclrhd@hotmail.com> wrote
Andy Little wrote:
"Reece Dunn" <msclrhd@hotmail.com> 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 :-) [cut] FWIW Heres my linker settings /OUT:"Debug/ReeceGui.exe" /INCREMENTAL /NOLOGO /LIBPATH:"XXX\boost_1_33_0\bin\boost\libs\signals\build\libboost_signals.lib\vc-7_1\debug\runtime-link-static" /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 [cut]
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 guess...
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 why 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 );
but:
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) [cut]
As far as compile time entities is concerned I think they could be very useful [snip] Might even be possible to use this for resource scripts...
These look great.
Thanks! [cut]
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. [cut]
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). [cut]
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 ! regards Andy Little