The SynSoft.D libraries 1.2 are now available from http://synsoft.org/d.html
There are several new small housekeeping modules, along with the
synsoft.win32.reg module that does registry stuff.
I've also changed the names of several methods in previous modules (I've
decided to standardise on ThisKindOfMethodName, rather than
this_kind_of_method_name()), but because of a linker weirdness - it
wouldn't link when there were start() and Start() methods in the same
class - the deprecated functions with the old names have had to be removed.
Apologies if this causes problems. ;/
The registry library, like the other ones, is a header-only from a
source-perspective (i.e. the method bodies are stripped). This is not
because I'm being precious, just that I only want any attention you may give
on the module's API, not the implementation. Once this module is matured, it
may be going into Phobos, at which point, obviously, all source will be
available.
Note that the reg module only does enumeration for the moment. I've not yet
decided on the format for adding/deleting keys/values, and am happy to hear
some suggestions from anyone.
Alas, there are still no test programs, but I'm including my test program
for the registry module here. Version 1.3 of the libraries will have test
and sample progs, I promise.
(I've got to toddle off and do some other things - deadlines, deadlines -
but I'll be keeping an eye on the ng, and will try to respond to
feedback/questions/abuse. ;) )
Enjoy!
--
Matthew Wilson
STLSoft moderator and C++ monomaniac
(http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
(www.synesis.com.au/articles.html#columns)
"An Englishman by birth, a Yorkshireman by the grace of God" -- Michael
Gibbs
----------------------------------------------------------------------------
---

The SynSoft.D libraries 1.2 are now available from http://synsoft.org/d.html
There are several new small housekeeping modules, along with the
synsoft.win32.reg module that does registry stuff.
I've also changed the names of several methods in previous modules (I've
decided to standardise on ThisKindOfMethodName, rather than
this_kind_of_method_name()), but because of a linker weirdness - it
wouldn't link when there were start() and Start() methods in the same
class - the deprecated functions with the old names have had to be removed.
Apologies if this causes problems. ;/
The registry library, like the other ones, is a header-only from a
source-perspective (i.e. the method bodies are stripped). This is not
because I'm being precious, just that I only want any attention you may give
on the module's API, not the implementation. Once this module is matured, it
may be going into Phobos, at which point, obviously, all source will be
available.

Are the stripped headers provided? I couldn't find any in
synsoft.D.1.2.zip or synsoft.D.1.2-libs.zip. When I tried to compile
the program the compiler says:
Error: Error reading file 'synsoft\win32\perf.d'

Note that the reg module only does enumeration for the moment. I've not yet
decided on the format for adding/deleting keys/values, and am happy to hear
some suggestions from anyone.
Alas, there are still no test programs, but I'm including my test program
for the registry module here. Version 1.3 of the libraries will have test
and sample progs, I promise.
(I've got to toddle off and do some other things - deadlines, deadlines -
but I'll be keeping an eye on the ng, and will try to respond to
feedback/questions/abuse. ;) )
Enjoy!

Thanks. It sounds great. The .exe's you "released" earlier worked fine.
Justin

The registry library, like the other ones, is a header-only from a
source-perspective (i.e. the method bodies are stripped). This is not
because I'm being precious, just that I only want any attention you may

on the module's API, not the implementation. Once this module is

may be going into Phobos, at which point, obviously, all source will be
available.

Are the stripped headers provided? I couldn't find any in
synsoft.D.1.2.zip or synsoft.D.1.2-libs.zip. When I tried to compile
the program the compiler says:
Error: Error reading file 'synsoft\win32\perf.d'

Gah! What a dodo!!
I shall rectify right now. <blush>

Note that the reg module only does enumeration for the moment. I've not

decided on the format for adding/deleting keys/values, and am happy to

some suggestions from anyone.
Alas, there are still no test programs, but I'm including my test

for the registry module here. Version 1.3 of the libraries will have

and sample progs, I promise.
(I've got to toddle off and do some other things - deadlines,

but I'll be keeping an eye on the ng, and will try to respond to
feedback/questions/abuse. ;) )
Enjoy!

Thanks. It sounds great. The .exe's you "released" earlier worked fine.

Ok, they should be up there now. Try again ...
"J C Calvarese" <jcc7 cox.net> wrote in message
news:bk5g1c$gi0$1 digitaldaemon.com...

Matthew Wilson wrote:

The SynSoft.D libraries 1.2 are now available from

There are several new small housekeeping modules, along with the
synsoft.win32.reg module that does registry stuff.
I've also changed the names of several methods in previous modules (I've
decided to standardise on ThisKindOfMethodName, rather than
this_kind_of_method_name()), but because of a linker weirdness - it
wouldn't link when there were start() and Start() methods in the same
class - the deprecated functions with the old names have had to be

Apologies if this causes problems. ;/
The registry library, like the other ones, is a header-only from a
source-perspective (i.e. the method bodies are stripped). This is not
because I'm being precious, just that I only want any attention you may

on the module's API, not the implementation. Once this module is

may be going into Phobos, at which point, obviously, all source will be
available.

Are the stripped headers provided? I couldn't find any in
synsoft.D.1.2.zip or synsoft.D.1.2-libs.zip. When I tried to compile
the program the compiler says:
Error: Error reading file 'synsoft\win32\perf.d'

Note that the reg module only does enumeration for the moment. I've not

decided on the format for adding/deleting keys/values, and am happy to

some suggestions from anyone.
Alas, there are still no test programs, but I'm including my test

for the registry module here. Version 1.3 of the libraries will have

and sample progs, I promise.
(I've got to toddle off and do some other things - deadlines,

but I'll be keeping an eye on the ng, and will try to respond to
feedback/questions/abuse. ;) )
Enjoy!

Thanks. It sounds great. The .exe's you "released" earlier worked fine.
Justin

There've been quite a few downloads, which is nice. :)
Please let me have all your feedback, good or bad.
Cheers
Matthew
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bk5cki$bsj$1 digitaldaemon.com...

The SynSoft.D libraries 1.2 are now available from

There are several new small housekeeping modules, along with the
synsoft.win32.reg module that does registry stuff.
I've also changed the names of several methods in previous modules (I've
decided to standardise on ThisKindOfMethodName, rather than
this_kind_of_method_name()), but because of a linker weirdness - it
wouldn't link when there were start() and Start() methods in the same
class - the deprecated functions with the old names have had to be

Apologies if this causes problems. ;/
The registry library, like the other ones, is a header-only from a
source-perspective (i.e. the method bodies are stripped). This is not
because I'm being precious, just that I only want any attention you may

on the module's API, not the implementation. Once this module is matured,

may be going into Phobos, at which point, obviously, all source will be
available.
Note that the reg module only does enumeration for the moment. I've not

decided on the format for adding/deleting keys/values, and am happy to

some suggestions from anyone.
Alas, there are still no test programs, but I'm including my test program
for the registry module here. Version 1.3 of the libraries will have test
and sample progs, I promise.
(I've got to toddle off and do some other things - deadlines, deadlines -
but I'll be keeping an eye on the ng, and will try to respond to
feedback/questions/abuse. ;) )
Enjoy!
--
Matthew Wilson
STLSoft moderator and C++ monomaniac
(http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
(www.synesis.com.au/articles.html#columns)
"An Englishman by birth, a Yorkshireman by the grace of God" -- Michael
Gibbs
--------------------------------------------------------------------------

There've been quite a few downloads, which is nice. :)
Please let me have all your feedback, good or bad.
Cheers
Matthew

I'm gonna look at GConf now.
"GConf is a system for storing application preferences."
(Took me what? 1 hour just to find that it exist)
Do you think we could integrate GConf and your win32.reg in a
common interface? Is that desirable?
Is that possible at all?
what's the license on your libs?
I'll know more about GConf tomorrow.
Ant
(yeah, DUI for windows is boring is anybody out there
interested in tweeking the makefiles and stuff like that
to make it run? I should make a separate post with this)

Ant
I'm afraid I know nothing about GConf, so can't comment.
As regards the registry library, as soon as Walter's finished some essential
compiler-waltering on the C++ compiler we'll be putting the registry API
into Phobos, and releasing the next version, so it'll be best if you can
hang fire a little while, and then it'll all be available in its majesty,
ready for digestion and potential regurgitation. :)
If the reg and GConf are in any way similar, I'd certainly like to
investigate a potential merge. I'd probaby prefer that there was a separate
common module, perhaps DConf, which could be implemented in terms of the reg
module on Win32, and the appropriate technology on Linux. Does that sound
sensible?
Cheers
Matthew
"Ant" <Ant_member pathlink.com> wrote in message
news:blg2mo$bdf$1 digitaldaemon.com...

In article <bk949o$191s$1 digitaldaemon.com>, Matthew Wilson says...

There've been quite a few downloads, which is nice. :)
Please let me have all your feedback, good or bad.
Cheers
Matthew

I'm gonna look at GConf now.
"GConf is a system for storing application preferences."
(Took me what? 1 hour just to find that it exist)
Do you think we could integrate GConf and your win32.reg in a
common interface? Is that desirable?
Is that possible at all?
what's the license on your libs?
I'll know more about GConf tomorrow.
Ant
(yeah, DUI for windows is boring is anybody out there
interested in tweeking the makefiles and stuff like that
to make it run? I should make a separate post with this)

A tree struct that holds key/value pairs,
(if it's not that ignore the rest of this)
and more (a value can be a list) but the common interface would
leave out the "uncommon" features (wouldn't you know...)
There is a GConf client that looks a lot like the regedit.exe
(for win9x I didn't check latelly)

As regards the registry library, as soon as Walter's finished some essential
compiler-waltering on the C++ compiler we'll be putting the registry API
into Phobos, and releasing the next version, so it'll be best if you can
hang fire a little while, and then it'll all be available in its majesty,
ready for digestion and potential regurgitation. :)
If the reg and GConf are in any way similar, I'd certainly like to
investigate a potential merge. I'd probaby prefer that there was a separate
common module, perhaps DConf, which could be implemented in terms of the reg
module on Win32, and the appropriate technology on Linux. Does that sound
sensible?

That's my idea.
I'm coding and experimental version that I named DConf :)
(copy/paste of course no fancy ,def files yet ;)
As I see it now, the DUI package will have 3 libs
libdui - core GTK,GDK,GLIB,Pango...
libduigl - OpenGL
libduiext - extensions (maybe divided into linux and windows versions(?))
The first extension is DConf (if it can migrate to phobos better).
For now I'm implementing it through the GTK+ wrapper 'cause it familiar
to me but it can be completly independent.
As to be integrated into phobos I'm not sure as I'm doing just a wrapper.
phobos would be dependent on a third party lib (BTW it LGPL).
GConf is a gnome system, probably KDE will have it's own, I don't
know about others...
(Is it starting to get complicated?...)
Let's wait and see.
Ant

A tree struct that holds key/value pairs,
(if it's not that ignore the rest of this)
and more (a value can be a list) but the common interface would
leave out the "uncommon" features (wouldn't you know...)

Sounds great. I'd be very happy if the D.win32.registry module could serve
as an exemplar for such a thing, as well as being used in its Win32
implementation

There is a GConf client that looks a lot like the regedit.exe
(for win9x I didn't check latelly)

Where does it store its stuff? Is it system global, or can each process have
its own reg file?

As regards the registry library, as soon as Walter's finished some

compiler-waltering on the C++ compiler we'll be putting the registry API
into Phobos, and releasing the next version, so it'll be best if you can
hang fire a little while, and then it'll all be available in its majesty,
ready for digestion and potential regurgitation. :)
If the reg and GConf are in any way similar, I'd certainly like to
investigate a potential merge. I'd probaby prefer that there was a

common module, perhaps DConf, which could be implemented in terms of the

module on Win32, and the appropriate technology on Linux. Does that sound
sensible?

That's my idea.
I'm coding and experimental version that I named DConf :)
(copy/paste of course no fancy ,def files yet ;)

I'm gonna look at GConf now.
"GConf is a system for storing application preferences."
(Took me what? 1 hour just to find that it exist)

I would not recommend making GConf and the registry the same API - they
look the same but really are quite different.
For instance:
* GConf entries must (?) have schemas that give key documentation,
possible values etc
* GConf key types are different
* GConf notifications are used a lot more than win32 registry
notifications are
* GConf is not guaranteed to be available on any given Linux system in the
same way the registry is.
* GConf is not meant to be used to store arbitrary data like the registry
is, it's supposed to be for app preferences only (hence the powerful
application defaults/lockdown settings)

Do you think we could integrate GConf and your win32.reg in a
common interface? Is that desirable?

I would generally recommend that D bindings have the same name as what
they bind to (so import gtk rather than import dui) and are direct
mappings rather than abstractions.
If somebody wants to use the registry and GConf in the same way
they can always write their own simple abstraction class on top of them,
IMHO, and use the versioning stuff in D to let it figure itself out.

I'm gonna look at GConf now.
"GConf is a system for storing application preferences."
(Took me what? 1 hour just to find that it exist)

I would not recommend making GConf and the registry the same API - they
look the same but really are quite different.
For instance:
* GConf entries must (?) have schemas that give key documentation,
possible values etc

??

* GConf key types are different

That's why we need an abstraction layer

* GConf notifications are used a lot more than win32 registry
notifications are

Don't see it as a problem

* GConf is not guaranteed to be available on any given Linux system in the
same way the registry is.

That's a real problems.

* GConf is not meant to be used to store arbitrary data like the registry
is, it's supposed to be for app preferences only (hence the powerful
application defaults/lockdown settings)

Do you think we could integrate GConf and your win32.reg in a
common interface? Is that desirable?

I would generally recommend that D bindings have the same name as what
they bind to (so import gtk rather than import dui) and are direct
mappings rather than abstractions.

I'm even thinking of remove all the gtk tokens from DUI.
(probably a mistake(?) I'll take another look at it)

If somebody wants to use the registry and GConf in the same way
they can always write their own simple abstraction class on top of them,
IMHO, and use the versioning stuff in D to let it figure itself out.

My first idea was to have that.
except for the "their own" part.
Integrating it into phobos might be too ambitious...
Thanks for your insights!
Ant