[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Initial thoughts...



I haven't actually converted my application over to use V but somethings
I came across...

- I like the size and simplicity... a lot. With the library I was
previously using I always had to link in no fewer than 12 additional
Windows libraries (user32, kernel32, gdi32, advapi32... etc) just to get
a VC++ or mingw32 egcs executable because of the libraries do
everything, be everything approach.
- For my own uses I imported the code into my CVS server and rearranged
it to work with the YSL (www.ysl.org) makefile system so I can keep
flags the same as well as keep things familiar. It was easy to do and I
appreciate it... the way things are laid out it looks like it will be
easy to incoporate.
- Would you be against me implementing and submitting an event handling
system more or less like what OWL, MFC, wxWindows, etc. use? Basically
is this something that would be liked or is it something that is loathed
on this project? From the looks of things there is just one main handler
and the client implements a switch statement to call the handlers.
- Is there a Coding Style guidelines document? I realize coding style is
personal preference.... V seems to use a very unique format.
- The v*Cmd (vButtonCmd, vTextCmd) naming conventions are interesting
since they are usually associated with controls... I still have a *lot*
of looking around before I understand the V paradigm so I'm sure there
is a reason I have yet to find that they are associated with commands
and not controls.

Which I think how I'm going to go about this (if any cares:)...
YSL : provide standard libraries... string, vector, threads, ipc,
container classes
V: GUI framework
wxWindows: strip it down to the graphics libraries (jpeg, png, etc) and
create some V based image objects as necessary to interface with the
user

Brian Macy


Reply to: