Re: GWindows and David Botton

[Fionn mac Cuimhaill <invisible@hiding.from.spam>]

On 25 Sep 2004 08:01:25 -0400, Stephen Leake <stephen_leake@acm.org>
wrote:

>Fionn mac Cuimhaill <invisible@hiding.from.spam> writes:
>
>> OK, that sounds fine to me -  I will go with comp.lang.ada as a
>> communication medium  I have neve done anything with Sourceforge other
>> than download software from it. Does anyone here who might want to
>> work on GWindows have any experience with it? 
>
>I'm an administrator on the Grace project on Savannah; I believe
>Sourceforge is similar.
>
>Note that Grace is no longer active.
>
>> In any case, I will investigate Sourceforge myself and see what it
>> takes to start a new project there.
>
>Ok. Please don't start one until we get some agreement about who's
>going to be a member. We might not want to call it Gwindows :).
>
>We should take seriously Randy's offer to open up the rest of Claw. I
>have not examined much of Claw or Gwindows (I have of course read all
>of Windex :), but from what I remember, I believe Claw is the best
>structured of the three.
>
>I'll download the current Gwindows and Claw and give them another
>look.
>
>But if there are enough people already using Gwindows, it makes sense
>to go with that.
>
>> And to get started, I would like to start laying out a roadmap of
>> things that need to get done.  I can think of several areas that can
>> stand some more work.
>
>Ok.
>
>> 1. Documentation. The existing tutorial intro is a good start, but
>> it needs much work, as do the associated tutorial examples. For
>> example, there is no section in the tutorial intro about the use of
>> radio buttons, and there is no corresponding example program.
>> 
>> Some of the examples show several variations of ways to do things,
>> which might be best broken up into several independent example
>> programs. The numbering scheme for tutorial programs needs to be
>> changed so that new ones can be added without renumbering all of the
>> later ones.
>
>Tutorials are always good, and always hard to get people to write. I
>wrote test code for Windex, but not a tutorial. It is a good idea to
>keep it on the List of Things To Do :).
>
>Speaking of which, test code should also be included, preferably for
>every package. I've got a GUI test driver framework for Win32 that
>works quite nicely.
>
>> A reference manual is needed.
>
>I hope that the Ada specs can be the reference manual, given a good
>tutorial and the MS API documentation. Again, getting people to write
>documentation is hard.
>
>> Documentation should be available in some form other than Word, as not
>> everybody has or likes it. Anybody can get a free Adobe pdf reader,
>> and I can easily create documents in that form. (I actually like
>> WordPerfect, but few use it nowadays, although it can easily produce
>> both pdf and html outputs.)
>
>PDF is definitely the way to go for distribution. I prefer LaTeX for
>the source format; it works nicely with CVS for change control.
LaTeX is OK with me - I started with LaTeX 15 years ago, which I used
to document a large Fortran project that had grown up over several
years without adequate documentation.
>
>> 2. Bugs need to be identified and fixed. I hereby call for bug
>> reports, so that we can look to see what needs to be done.
>
>Sourceforge has a nice bug reporting and tracking feature.
>
>> 3. Deficiencies in existing areas need to be addressed. An example
>> here is edit boxes. There seems to be no general way to capture
>> character entered into an edit box and do special handling for
>> things like carriage returns. In general, if Visual Basic can do
>> something, GWindows should be able to do the same thing.
>
>Yes, that's a good guideline. 
>
>> 4. Expansion areas need to be identified. Printing is important for
>> me. I want to do printing additions in two stages. The first level
>> should bring printing support up to a rough equivalent of what can
>> be done with Visual Basic 6, but done in a more coherent Ada way.
>> The second level needs to add some kind of higher-level document
>> abstraction. I have in mind something like the qPrinter package for
>> Visual Basic 6. (Google for qPrinter and you will find it
>> immediately.)
>
>This raises the issue of architecture control. Will the Gwindows
>project be a cathedral or a bazarre? Do we want to form a group that
>requires consensus on major design decisions (like this one), or just
>a set of people who happen to share a CVS repository?
Some concensus is certainly desirable, as it will help to keep a good
team together. However, I don't want to build a GWindows architecture
that makes different ways of doing things impossible. In the printing
project that I want to do, I want to build a Gwindows printer object
similar in concept to the VB printer object, so that it can form a
stable base for higher level abstractions. For now, I'll call it
GPrinterObject. I would like to build a printable document abstraction
on top of that (GDocument)   I want to keep the two cleanly separated,
so that other printing projects using a quite different design
philosophy can be built on top of GPrinterObject. 
>
>In general, I prefer a consensus design, but it can be difficult to
>manage.
>
>> The existing thin binding to the Windows printing API should not be
>> neglected - various API functions are missing and should be added.
>
>Ok.
>
>> 5. Various extensions need to be done to character string handling.
>> Gwindows tries to hide the difference between  character
>> representation among the various versions of Windows by defining a
>> GString to be composed of either ordinary or wide characters as
>> needed, and likewise tries to hide the differences between various
>> Windows API procedures and functions that use string arguments. This
>> hiding philosophy in not completely implemented and  I still need to
>> use a variety of Ada system packages that have both ordinary and
>> wide-character versions. (Typically the wide versions, as I do all of
>> my development on Windows 2K and XP)
>
>Hmm. In Windex I supported both Character and Wide-Character as I
>needed to. I'd prefer that over "hidden magic". But I'm not familiar
>with all the localization issues; I've seen some messages here that
>imply we really need a Wide-Wide-Character.
The "hidden magic" of the GString character type is quite simple, but
it is used almost everywhere in GWindows where character strings are
needed. It would be simpler to proceed with that philosophy rather
that to change it.
>
>> I'm going to need help; I am far from being the best Ada programmer in
>> the world 
>
>I can help there :).
>
>> and I know little about low-level Windows API programming. 
>
>I recommend you buy "Win32 Programming" by Brent E. Rector, Joseph M.
>Newcomer. It covers most of the Win32 API, using just C. That makes it
>easy to figure out how to do the same things in Ada. It's a little old
>(1997), but it does a very good job of explaining all the things that
>MS leaves out of their documentation.
>
>Another good book is "Programming Windows" by Charles Petzold. That's
>more tutorial oriented, and doesn't cover as much of the API as "Win32
>Programming".
>
>At the same time, the MS API documentation is online at
>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winprog/winprog/windows_api_reference.asp
>; it is quite readable (once you've read "Win32 Programming" :).
>
>> If all goes well, both of those situations will change for the
>> better as this project develops.
>
>Yes, that's true :).