1. Suggestions and Stuff
Here's a smattering of ideas:
[Internationalization]
One neat thing that KDE (K Desktop Environment) has is a automatic
internationalization feature, something that I've been promising for
Win32Lib. For example, the code to set a menu item looks something like
this:
menu->insertItem( klocale->translate("File"), file );
The key function here is translate(), which returns the string as a word in
the currently selected language. Since most Windows applications seem to
share a fairly large set of common labels ("File", "Open", "Cancel"), it
doesn't take a huge dictionary to port 90% of an application to another
language. And the neat thing is that it's done automatically, so you don't
have to have seperate resource files.
Sure, the more complex messages are not handled, but I think it would
certainly be a major step in the right direction.
I could probably go spelunking through KDE and find the lookup table, but
perhaps someone out there is more motivated that I am, and can do it
faster - or at least a list of words could be compiled. It seems to me that
such a function would be a nice addition to virtually any Euphoria
application, from Win32Lib to video games.
[Automatic Updates]
One of the features on a lot of programs coming out these days is the
ability to check on the web for the most current version of the code. This
might also make a nice addition to Euphoria, although I suspect that it
would only work for unbound programs, for obvious reasons. For example, it
would take care of the problem of not having the most up-to-date libraries
installed in an application, or perhaps just not having the most current
version of a program.
Any takers? Perhaps if it was written, Robert could donate a web page for
Euphoria programs with an auto-update feature, so there would be a stable
web page to post updates to.
[Messages and Namespace]
As with most OOP programs in Euphoria (Quartz also comes to mine), the
rewrite of Win32Lib grapples with the question of passing messages as
strings or integers. For example:
send( window, "open", {} )
or:
send( window, OPEN, {} )
The advantage of using strings is that you don't get conflicts between
classes. That is, if I define a class FOO that uses SET as a message and you
define a class BAR that uses the message SET, there is a conflict. Languages
like C++ avoid the name conflict by binding the name to the class, so
FOO.SET and BAR.SET don't collide.
The down side is that strings are slower - especially since Euphoria
optimizes integer stuff. And there is more overhead with having to pass
strings. What to do?
One option I've been toying with is setting up a dictionary along these
lines:
sequence registry
registry = {}
global function register( sequence s )
-- return the index of s in the registry
integer index
-- has the word been registered yet?
index = find( s, registry )
if index then
return index
end if
-- add the word to the registry
registry = append( registry, s )
-- return index
return length( registry )
end function
So you can define your messages as local constants:
constant
xSet = register( "set" ),
xGet = register( "get" )
and they will map to the same index from one include file to the next, but
you won't have to worry about name conflicts, since the constants are all
declared locally. So xSet and xGet are scoped to their include file (which
is the same as their class), much in the same way as C++ does it.
Comments?
-- David Cuny
2. Re: Suggestions and Stuff
At 12:26 AM 3/31/99 -0800, you wrote:
>
>
>So you can define your messages as local constants:
>
> constant
> xSet = register( "set" ),
> xGet = register( "get" )
>
>and they will map to the same index from one include file to the next, but
>you won't have to worry about name conflicts, since the constants are all
>declared locally. So xSet and xGet are scoped to their include file (which
>is the same as their class), much in the same way as C++ does it.
>
>Comments?
>
>-- David Cuny
Will Quartz be adopting this method? I know you (David Cuny) aren't doing
Quartz, so only the person with the inside scoop should answer. 
I mean, it's not like I need any software optimization on my PII-450, 128MB
RAM, and with the P-III and faster machines coming available, will it
really matter if we use strings or integers?
I like the object.method way myself, but I'm flexible and open to whatever
works and works well.
Thanks!
ck
P.S. I think we should start a David Cuny Win32Lib Fund or something.
3. Re: Suggestions and Stuff
At 12:26 AM 3/31/99 -0800, you wrote:
>>
>>
>>So you can define your messages as local constants:
>>
>> constant
>> xSet = register( "set" ),
>> xGet = register( "get" )
>>
>>and they will map to the same index from one include file to the next, but
>>you won't have to worry about name conflicts, since the constants are all
>>declared locally. So xSet and xGet are scoped to their include file (which
>>is the same as their class), much in the same way as C++ does it.
>>
>>Comments?
>>
>>-- David Cuny
>
>Will Quartz be adopting this method? I know you (David Cuny) aren't doing
>Quartz, so only the person with the inside scoop should answer.
Well, it does seem like a promising idea. I'm just hesitant because
of the way it'll work in the code; no longer will you only need the
5 Quartz functions, you'll also need to set up a list of constants in
each file before using them. Hmmm... I'm not going to obligate myself,
but I will look into it. There may be a way to have cake and eat it
too.
Rod Jackson
4. Re: Suggestions and Stuff
C. K. Lester wrote:
> I mean, it's not like I need any software optimization on
> my PII-450, 128MB RAM, and with the P-III and faster machines
> coming available, will it really matter if we use strings or integers?
I wondered about that before I posted this. In my code, *all* classes share
the same methods, even if they don't choose to implement them. I figured
that memory is cheap. In Quartz, it's less of a problem, since the search
space for methods is fairly small.
My suspicion is that the cost is probably not as high as I think it is. The
real expense in the classes is probably in the calls to routine_id, which
has to place all the values into a new sequence before making the call. This
gets even more expensive if the OOP supports inheritance, since a call to a
class results into a call to it's base class, and so on.
> I like the object.method way myself, but I'm flexible and
> open to whatever works and works well.
I don't think that Robert will be adopting that syntax in the near future. I
think it would be a nice feature, but there are probably a lot of
far-reaching ramifications, like having to wait until run time to resolve
names.
> P.S. I think we should start a David Cuny Win32Lib Fund or something.
Thanks, but money isn't the problem - it's time and burnout. I used to have
a lot more time, until kid #2 came along. Unlike his brother, he runs at
full throttle all day long. So I seem to have a lot less time and energy
than I did before. Plus, projects like Win32Lib are never ending - there's
always a new feature to implement, or a bug to fix.
That's why I'm rewriting WinLib from the ground up - the next version should
allow extending the core merely by adding self-contained include files. That
gets the bulk of the work off my shoulders, and onto people who are
rightfully itching for new features.
Work is moving slowly in the right direction - the core WinLib code looks
more and more like WinMan. It's a lot of "one step forward, two steps back"
kind of thing - it's difficult to disentangle a lot of Win32 dependancies
and make the classes clean. I won't promise any delivery dates, but as soon
as I get two basic classes up (a window and a pushbutton) I'll be posting
the code for feedback.
-- David Cuny
5. Re: Suggestions and Stuff
At 11:44 AM 3/31/99 -0800, you wrote:
>C. K. Lester wrote:
>
>> P.S. I think we should start a David Cuny Win32Lib Fund or something.
>
>Thanks, but money isn't the problem - it's time and burnout. I used to have
>a lot more time, until kid #2 came along. Unlike his brother, he runs at
>full throttle all day long. So I seem to have a lot less time and energy
>than I did before. Plus, projects like Win32Lib are never ending - there's
>always a new feature to implement, or a bug to fix.
Well, I figure with a big enough fund, you could quit your day job...
(Chauvenistic, but joking, comments about "How come the wife ain't raising
the kids and lettin' you get some work done" snipped before posted...hehehoooo)
Optimally, you could get on the RDS payroll.
>and make the classes clean. I won't promise any delivery dates, but as soon
>as I get two basic classes up (a window and a pushbutton) I'll be posting
>the code for feedback.
>
>-- David Cuny
I'm actually here to ask when will Quartz objects for windows and window
object thingies (buttons, etc.) be available, if not already...?
The EUPHORIC world waits in anticipation for your further developments,
David. Would you be able to outsource some of your coding, or turn Win32Lib
into a group project, or has it simply been nobody else has the knowledge
to do what you're doing?
Regardless, I offer big thanks to you and what you've done for the
EU-Windows effort.
6. Re: Suggestions and Stuff
C. K. Lester wrote:
> I'm actually here to ask when will Quartz objects for windows
> and window object thingies (buttons, etc.) be available, if not
> already...?
If someone wanted to wrap the Win32 API with Quartz, that's certainly
feasible. That's essentially what the Win32Lib rewrite is doing, except that
I'm not using Quartz.
> Would you be able to outsource some of your coding, or turn
> Win32Lib into a group project, or has it simply been nobody
> else has the knowledge to do what you're doing?
There are certainly many other people in this group that are quite
knowledgeable in Win32 coding, and much more than me. The issue is that I'm
still in design mode. At this point, the code goes through *major* changes
each time I work on it, and there are a lot of design decisions that are yet
to be finalized.
As soon as I have a working window with a pushbutton in it, I'll be posting
the code. At that point, I hope be able to turn it into a group project, and
have other people complete the remaining classes, as well as create new
ones. Then I can start working on the Generic class for Dos32...
But don't hold your breath - it probably won't be ready for at least a month
or more, especially since I'm due for a vacation next month.
> Regardless, I offer big thanks to you and what you've done for the
> EU-Windows effort.
Thanks! 
-- David Cuny
