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

Re: Initial thoughts...



Seems to me if you are looking for a multiplatform GUI that doesn't cost $e3, the main points to consider are:

* source available?
* consistancy in look and feel across platforms (so your GUI looks the same)?
* has the GUI elements you need?
* bug free (reasonably)?
* has support from its developers?
* has a user community to get assistance/examples from?
* has a good track record?

While V does not all the visual bells and whistles I would like, it does have all the essentials I need for my multi-platform apps. The other criteria all have "yes" answers.

Naming conventions, style, class organization, etc, while fun to argue about over a beer, provide no input as to the multiplatform and GUI capabilities of the library (btw, coding style is in the V reference). If you're looking for most everything in OWL, C++ Builder, etc., you'll need to go with a commercial platform like Zinc (big $). Nothing in my experience compares with the speed of GUI development that Builder provides, but with V, multiplatform GUI is the critical consideration. 

I have built complex GUI's that are fairly easy to use in environmental chemistry and ecological modelling applications. V has been perfect for these apps. In combination with a binary-portable file format (netCDF), I have true cross-platform (Windows and X) software and data.

Cheers...
Tom Hilinski


----- Original Message ----- 
From: Brian Macy <bmacy@sunshinecomputing.com>
To: <bruce@objectcentral.com>
Cc: VGUI discuss <vgui-discuss@other.debian.org>; <strobert@strobe.net>
Sent: Monday, July 19, 1999 12:18 PM
Subject: 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
| 
| 
| -- 
| To UNSUBSCRIBE, email to other-vgui-discuss-request@other.debian.org
| with a subject of "unsubscribe". Trouble? Contact listmaster@other.debian.org



Reply to: