www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - minwin

reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Hi folks.
Just want to tell people that I have uploaded a zip with a MinWin that 
builds on DMD 0.175.

Check it at:
http://wiki.dprogramming.com/MinWin/HomePage

it only really took fixing the private/public import changes but it was 
boring and I figure someone else might like to avoid it...

- lindquist
Nov 27 2006
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Tomas Lindquist Olsen wrote:

 Hi folks.
 Just want to tell people that I have uploaded a zip with a MinWin that 
 builds on DMD 0.175.
 
 Check it at:
 http://wiki.dprogramming.com/MinWin/HomePage
 
 it only really took fixing the private/public import changes but it was 
 boring and I figure someone else might like to avoid it...
 
 - lindquist


That's pretty nice.  Like wxWidgets-lite in D.

I see there's some talk on the forum about putting this into SVN 
somewhere.  Why not DSource?

Also, I can't get the sample.exe to do anything.  All the other samples 
work fine, though.  It seems if I comment out the 'new Button' lines it 
works.

--
I'll just put in a plug for what I'd like to see in such a library: it 
should be possible to use the standard dialogs (like message box, file 
dialog, etc) without having to buy into the rest of the app framework 
stuff.

Right now it seems it's not possible in MinWin because it insists on you 
using its MinWinMain.  However, I tried adding a simple 
'version(NOMAIN)' in the Windows part of app.d, to enable opting out of 
that.  Then this no-gui program is able to open dialogs using MinWin's 
wrappers:

----------------
import minwin.dialog;
import minwin.window;
import std.string;
import std.stdio;

class NullWin : AbstractWindow
{
     WindowPeer peer = null;
}

void main()
{
     scope win = new NullWin;

     FileDialogData data;
     data.title = "Open File";
     if (openFileDialog(win,data)) {
         char[] text = "you selected " ~ data.result;
         informationDialog(win, "Hello, world!\n"~text, "Greeting");
     }
}
----------------

This would be nice because it would, for instance, give OpenGL GUIs 
(like say Luigi[1] ;-)) an easy way to invoke native dialogs without 
having to switch whole hog from a simple GL-oriented toolkit like GLD or 
SDL to something else less GL-friendly.

[1] http://www.dsource.com/projects/luigi

--bb
Nov 27 2006
parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Bill Baxter wrote:

 Tomas Lindquist Olsen wrote:

 Hi folks.
 Just want to tell people that I have uploaded a zip with a MinWin that 
 builds on DMD 0.175.

 Check it at:
 http://wiki.dprogramming.com/MinWin/HomePage

 it only really took fixing the private/public import changes but it 
 was boring and I figure someone else might like to avoid it...

 - lindquist


 
 That's pretty nice.  Like wxWidgets-lite in D.
 
 I see there's some talk on the forum about putting this into SVN 
 somewhere.  Why not DSource?
 
 Also, I can't get the sample.exe to do anything.  All the other samples 
 work fine, though.  It seems if I comment out the 'new Button' lines it 
 works.
 
 -- 
 I'll just put in a plug for what I'd like to see in such a library: it 
 should be possible to use the standard dialogs (like message box, file 
 dialog, etc) without having to buy into the rest of the app framework 
 stuff.
 
 Right now it seems it's not possible in MinWin because it insists on you 
 using its MinWinMain.  However, I tried adding a simple 
 'version(NOMAIN)' in the Windows part of app.d, to enable opting out of 
 that.  Then this no-gui program is able to open dialogs using MinWin's 
 wrappers:
 
 ----------------
 import minwin.dialog;
 import minwin.window;
 import std.string;
 import std.stdio;
 
 class NullWin : AbstractWindow
 {
     WindowPeer peer = null;
 }
 
 void main()
 {
     scope win = new NullWin;
 
     FileDialogData data;
     data.title = "Open File";
     if (openFileDialog(win,data)) {
         char[] text = "you selected " ~ data.result;
         informationDialog(win, "Hello, world!\n"~text, "Greeting");
     }
 }
 ----------------
 
 This would be nice because it would, for instance, give OpenGL GUIs 
 (like say Luigi[1] ;-)) an easy way to invoke native dialogs without 
 having to switch whole hog from a simple GL-oriented toolkit like GLD or 
 SDL to something else less GL-friendly.
 
 [1] http://www.dsource.com/projects/luigi
 
 --bb


It's an interesting use case, though I can't help think a seperate 
"dialogs" library would be better for this. Also currently MinWin does 
not even have a simple yes/no dialog (though it's pretty easy to add).

[rant]

For me MinWin seems very much like a winner as it is one of the only D 
gui libraries that work crossplatform and it doesn't try to do too much. 
  executables are pretty small compared to what you get from Harmonia as 
an example.
The posts I've done on the DSource forums would certainly suggest having 
a svn repository there. I'm not sure I'm the right guy for maintaining 
it though. I dont know GTK+ or Motif and only some fairly basic Win32, 
but I have a genuine interest in a crossplatform gui library that is 
easy to work with!
(I use Ultimate++ in C++ which btw is AWESOME!!!, even if the author 
luzr doesn't seem to like D) :P

What I'd really like to see for MinWin is active development. From 
looking at the todo list it seems quite a lot was still planned and 
there are known bugs as well.

D seems such a perfect language to do gui applications. It's really a 
shame the toolkits don't step up to it.

[/rant]
Nov 27 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Tomas Lindquist Olsen wrote:

 Bill Baxter wrote:

 Tomas Lindquist Olsen wrote:

 Hi folks.
 Just want to tell people that I have uploaded a zip with a MinWin 
 that builds on DMD 0.175.

 Check it at:
 http://wiki.dprogramming.com/MinWin/HomePage






[snip]

 This would be nice because it would, for instance, give OpenGL GUIs 
 (like say Luigi[1] ;-)) an easy way to invoke native dialogs without 
 having to switch whole hog from a simple GL-oriented toolkit like GLD 
 or SDL to something else less GL-friendly.

 [1] http://www.dsource.com/projects/luigi

 --bb


 
 It's an interesting use case, though I can't help think a seperate 
 "dialogs" library would be better for this. 


Well, the bulk of the code in this "dialogs" library would be identical 
to the dialog handling code in MinWin.  I only had to add 3 lines of 
code to MinWin to make the dialogs work stand-alone (for Windows 
version).  That code was:

     version(NOMAIN) {}
     else {
        [existing winmain code here...]
     }

(is there a way to do version(!NOMAIN)?)
I could see maybe breaking the dialogs part of MinWin into a separate 
sub-library, but I definitely don't see any reason why it should be a 
separate project.


 Also currently MinWin does 
 not even have a simple yes/no dialog (though it's pretty easy to add).
 
 [rant]
 
 For me MinWin seems very much like a winner as it is one of the only D 
 gui libraries that work crossplatform and it doesn't try to do too much. 
  executables are pretty small compared to what you get from Harmonia as 
 an example.


Part of the smallness is probably due to wrapping native widgets, and 
just not having all that much functionality to begin with.


 The posts I've done on the DSource forums would certainly suggest having 
 a svn repository there. I'm not sure I'm the right guy for maintaining 
 it though. I dont know GTK+ or Motif and only some fairly basic Win32, 
 but I have a genuine interest in a crossplatform gui library that is 
 easy to work with!


Well that's a good reason to put it on DSource.  It puts it in a much 
more neutral ground that one individual's personal web site, and makes 
transitioning of project lead and sharing of responsibilities easier. 
Also Trac is pretty sweet.


 (I use Ultimate++ in C++ which btw is AWESOME!!!, even if the author 
 luzr doesn't seem to like D) :P


Looks interesting.  Thanks for the link.  The one thing I was most 
curious about was whether it uses emulation or wrapping of native 
widgets.  But I can't find that mentioned anywhere.  All the screen 
shots seem to show a winXP kind of look and some clearly non-native 
widgets (like the color picker), so I'm thinking it's emulated with 
winXP look everywhere?  Is it themeable?

Whoa, though, that QTF is crazy!
http://www.ultimatepp.org/srcdoc$RichText$QTF$en-us.html
"WTF" is more what comes to mind... it seems so out of place in a 
toolkit that puts a priority on simplicity and clarity.

They should make T-Shirts:
   Got "{{1:2 A1::l40/60R6 3 A2::! B1:: B2}}"?


 
 What I'd really like to see for MinWin is active development. From 
 looking at the todo list it seems quite a lot was still planned and 
 there are known bugs as well.


Ok, why don't you go ahead and ask "admin AT dsource DOT org" for a 
WinMin page?


 D seems such a perfect language to do gui applications. It's really a 
 shame the toolkits don't step up to it.


Well, D is yet young.  These things take time.

--bb
Nov 28 2006
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bill Baxter wrote:


     version(NOMAIN) {}
     else {
        [existing winmain code here...]
     }
 
 (is there a way to do version(!NOMAIN)?)


A patch to do so has been rejected several times,
it's apparently "against the spirit" of version...
(it is supposed to be "positive" and not negative,
see Walter's earlier newsgroup posts* on the topic)

So your code above is the canonical D way to do it.

--anders

* e.g. digitalmars.D/37778, digitalmars.D/11995
Nov 28 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Anders F Björklund wrote:

 (is there a way to do version(!NOMAIN)?)




"Not no-how, not no-way!" -- the Cowardly Lion



 A patch to do so has been rejected several times,
 it's apparently "against the spirit" of version...
 (it is supposed to be "positive" and not negative,
 see Walter's earlier newsgroup posts* on the topic)


"Sir, you are employing a double negative." -- Mr. Spock
Nov 28 2006
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter Bright wrote:


 "Sir, you are employing a double negative." -- Mr. Spock


"Nobody helps nobody but himself." --Oxmyx

So are you saying that we should *not* write
"version(whatever) {} else" for D's #ifndef ?

--anders
Nov 28 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Anders F Björklund wrote:

 Walter Bright wrote:
 

 "Sir, you are employing a double negative." -- Mr. Spock


 
 "Nobody helps nobody but himself." --Oxmyx
 
 So are you saying that we should *not* write
 "version(whatever) {} else" for D's #ifndef ?


No, I'm saying one should not have properties that contain a negative, 
such as NOTMAIN or NOALIAS.
Nov 28 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter Bright wrote:


 So are you saying that we should *not* write
 "version(whatever) {} else" for D's #ifndef ?


 
 No, I'm saying one should not have properties that contain a negative, 
 such as NOTMAIN or NOALIAS.


Agreed. It's better to pick the positive - if possible.

I just think that is plusungood to not be able to express
my thoughts, just because it is against "good manners"...
But I guess I'm just too rooted in the Oldspeak languages.

I do have the feeling this is just "!is" all over again,
but I don't think it is meaningful to discuss it further.
If and when D gets !versions, it's easy to change "{} else".

--anders
Nov 29 2006
parent Walter Bright <newshound digitalmars.com> writes:
Anders F Björklund wrote:

 Walter Bright wrote:
 

 So are you saying that we should *not* write
 "version(whatever) {} else" for D's #ifndef ?


 No, I'm saying one should not have properties that contain a negative, 
 such as NOTMAIN or NOALIAS.


 
 Agreed. It's better to pick the positive - if possible.


A couple of times I've been briefly stumped trying to come up with the 
right positive, but every time I was able to figure one out, and was 
pleasantly surprised to discover that it was worth it - the code is more 
readable.

Note that I mean positive in the logic sense, not in the "think good 
thoughts" sense.
Nov 29 2006
prev sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
Walter Bright wrote:

 Anders F Björklund wrote:
 

 (is there a way to do version(!NOMAIN)?)




 
 
 "Not no-how, not no-way!" -- the Cowardly Lion



 
  > A patch to do so has been rejected several times,
  > it's apparently "against the spirit" of version...
  > (it is supposed to be "positive" and not negative,
  > see Walter's earlier newsgroup posts* on the topic)
 
 "Sir, you are employing a double negative." -- Mr. Spock


Yeh, ok, "not no main" is not a great example.

And actually I think if such a think existed the 'not' should be on the 
'version' instead of the identifier,
more like #ifndef VAR than #if !VAR

  !version(LeanAndMean) {
     // do some fatty stuff here
  }

The bottom line is, just because D doesn't have negative version checks, 
doesn't mean the need for them will go away.  It just means that
   "version(X){}else"
becomes the spelling of "!version".  I'd personally rather see 
!version(X) or not_version(X) than version(X){}else.

But either way it's not a big deal.  Just an odd thing to get all 
principled over.

--bb
Nov 28 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Bill Baxter wrote:

 The bottom line is, just because D doesn't have negative version checks, 
 doesn't mean the need for them will go away.  It just means that
   "version(X){}else"
 becomes the spelling of "!version".  I'd personally rather see 
 !version(X) or not_version(X) than version(X){}else.


Or perhaps rethink why there is a negative version called X in the first 
place. For example, if you want:

	version (!FULL) { }

it would perhaps be better to redo the version as:

	version (EMPTY) { }

I've been through this with my own code, and it definitely improves the 
readability to think in positive features rather than negative features. 
Something about how human perception works. Long ago I read that there's 
some research to back this up.

For example,

	version (NOFLOAT) => version (INTONLY)
	version (NOTWINDOWS) => version (LINUX)
Nov 28 2006
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:

 Bill Baxter wrote:

 The bottom line is, just because D doesn't have negative version 
 checks, doesn't mean the need for them will go away.  It just means that
   "version(X){}else"
 becomes the spelling of "!version".  I'd personally rather see 
 !version(X) or not_version(X) than version(X){}else.


 
 Or perhaps rethink why there is a negative version called X in the first 
 place. For example, if you want:
 
     version (!FULL) { }
 
 it would perhaps be better to redo the version as:
 
     version (EMPTY) { }
 
 I've been through this with my own code, and it definitely improves the 
 readability to think in positive features rather than negative features. 
 Something about how human perception works. Long ago I read that there's 
 some research to back this up.
 
 For example,
 
     version (NOFLOAT) => version (INTONLY)
     version (NOTWINDOWS) => version (LINUX)


Yeh, makes sense.  So putting a positive spin on it, the thing I want is 
something like version("LIBRARY") or version("CONSOLE")

But that doesn't change the fact that the version basically involves 
leaving out code, so I still will want to do:

       !version(LIBRARY)
       {
             int WinMain(...
       }

In this case what I really want, though, is to have a version(MAIN) 
that's the default, i.e. it's what you get without specifying any 
-version flags to dmd.


--bb
Nov 28 2006
prev sibling parent reply Gregor Richards <Richards codu.org> writes:
Walter Bright wrote:

 Bill Baxter wrote:

 The bottom line is, just because D doesn't have negative version 
 checks, doesn't mean the need for them will go away.  It just means that
   "version(X){}else"
 becomes the spelling of "!version".  I'd personally rather see 
 !version(X) or not_version(X) than version(X){}else.


 
 Or perhaps rethink why there is a negative version called X in the first 
 place. For example, if you want:
 
     version (!FULL) { }
 
 it would perhaps be better to redo the version as:
 
     version (EMPTY) { }
 
 I've been through this with my own code, and it definitely improves the 
 readability to think in positive features rather than negative features. 
 Something about how human perception works. Long ago I read that there's 
 some research to back this up.
 
 For example,
 
     version (NOFLOAT) => version (INTONLY)


version (BIGNUMONLY)
version (MATHUNSUPPORTED)
version (COMPLEXONLY)


     version (NOTWINDOWS) => version (LINUX)


I hate to say this, but that example just plain stupid. All it will ever 
do is limit your code to work on only certain operating systems. That's 
hindering portability, and that's no good.

As it turns out, it's often the case that such-and-such does work on 
every sane operating system, and therefore version (!Windows) makes sense.

I know I've ran into instances where $WEIRD_SOCKET_FEATURE_X crashes 
horribly on a certain operating system, so I was forced to #ifndef 
__APPLE__. The same feature worked fine on literally every other system 
I tested it on, so it would be ridiculous to do an #ifdef for everything 
BUT Apple.

version (darwin)
version (BSD)
version (Solaris)
version (SkyOS)
version (DJGPP)
version (HURD)
version (ObscureOS)
version (OSYetToBeInvented)


Thinking in positives is great, but so unrealistic as to be completely 
valueless. version statements in reality are used like indexes into 
sets. The set of operating systems, the set of C libraries, the set of 
compielrs. And it's unrealistic and ignorant to try to index EVERY 
member except for whichever one you like, especially since the list is 
always growing.

Not everything has a positive opposite. In fact, most everything doesn't.

  - Gregor Richards
Nov 28 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Gregor Richards wrote:

     version (NOTWINDOWS) => version (LINUX)


 I hate to say this, but that example just plain stupid. All it will ever 
 do is limit your code to work on only certain operating systems. That's 
 hindering portability, and that's no good.
 
 As it turns out, it's often the case that such-and-such does work on 
 every sane operating system, and therefore version (!Windows) makes sense.


I've seen a lot of code that did that, and it was nearly always broken. 
That's one motivation for operating system versions should be positives, 
not "this is for not windows" or "this is for not linux". Such 
fundamentally are wrong, and will bite you or the maintainer sooner or 
later.


 I know I've ran into instances where $WEIRD_SOCKET_FEATURE_X crashes 
 horribly on a certain operating system, so I was forced to #ifndef 
 __APPLE__. The same feature worked fine on literally every other system 
 I tested it on, so it would be ridiculous to do an #ifdef for everything 
 BUT Apple.
 
 version (darwin)
 version (BSD)
 version (Solaris)
 version (SkyOS)
 version (DJGPP)
 version (HURD)
 version (ObscureOS)
 version (OSYetToBeInvented)


What I'd do is have APPLE_SOCKET_BUG with the workaround, and the 
default for the else. That way, you can search for the workarounds for 
that bug, and they won't be confused with other apple features or other 
apple bugs. Furthermore, if apple fixes that bug, you can update your 
code much easier with a targeted update than if you painted the entire 
apple os that way.

It's common practice (such as in STL) to target specific bugs with 
specific identifiers, and then have a configuration file which sets up 
the bugs for each system.


 Thinking in positives is great, but so unrealistic as to be completely 
 valueless. version statements in reality are used like indexes into 
 sets. The set of operating systems, the set of C libraries, the set of 
 compielrs. And it's unrealistic and ignorant to try to index EVERY 
 member except for whichever one you like, especially since the list is 
 always growing.
 
 Not everything has a positive opposite. In fact, most everything doesn't.


I don't agree, and as an example I suggest the socket bug approach above.
Nov 28 2006
next sibling parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Walter Bright wrote:

 Gregor Richards wrote:

     version (NOTWINDOWS) => version (LINUX)


 I hate to say this, but that example just plain stupid. All it will 
 ever do is limit your code to work on only certain operating systems. 
 That's hindering portability, and that's no good.

 As it turns out, it's often the case that such-and-such does work on 
 every sane operating system, and therefore version (!Windows) makes 
 sense.


 
 I've seen a lot of code that did that, and it was nearly always broken. 
 That's one motivation for operating system versions should be positives, 
 not "this is for not windows" or "this is for not linux". Such 
 fundamentally are wrong, and will bite you or the maintainer sooner or 
 later.
 

 I know I've ran into instances where $WEIRD_SOCKET_FEATURE_X crashes 
 horribly on a certain operating system, so I was forced to #ifndef 
 __APPLE__. The same feature worked fine on literally every other 
 system I tested it on, so it would be ridiculous to do an #ifdef for 
 everything BUT Apple.

 version (darwin)
 version (BSD)
 version (Solaris)
 version (SkyOS)
 version (DJGPP)
 version (HURD)
 version (ObscureOS)
 version (OSYetToBeInvented)


 
 What I'd do is have APPLE_SOCKET_BUG with the workaround, and the 
 default for the else. That way, you can search for the workarounds for 
 that bug, and they won't be confused with other apple features or other 
 apple bugs. Furthermore, if apple fixes that bug, you can update your 
 code much easier with a targeted update than if you painted the entire 
 apple os that way.
 
 It's common practice (such as in STL) to target specific bugs with 
 specific identifiers, and then have a configuration file which sets up 
 the bugs for each system.
 

 Thinking in positives is great, but so unrealistic as to be completely 
 valueless. version statements in reality are used like indexes into 
 sets. The set of operating systems, the set of C libraries, the set of 
 compielrs. And it's unrealistic and ignorant to try to index EVERY 
 member except for whichever one you like, especially since the list is 
 always growing.

 Not everything has a positive opposite. In fact, most everything doesn't.


 
 I don't agree, and as an example I suggest the socket bug approach above.


This discussion has made me remember something I though about a while ago...
While I understand the reasoning for disallowing negated version 
identifiers / version statements from the above, I dont understand why 
we can't use logical operators with versions:

version(Windows)
{
     writefln("I know your OS");
}
else version(linux)
{
     writefln("I know your OS");
}
else version(darwin)
{
     writefln("I know your OS");
}
else
{
     writefln("I don't know your OS");
}

VS.

version(Windows || linux || darwin)
{
     writefln("I know your OS");
}
else
{
     writefln("I don't know your OS");
}

This genuinely reduces code duplication and is thus according to 
standard D mentality: less prone to be buggy, easier to maintain, and 
faster to write.
Though if something like this was to be allowed, && and ! probably 
should be as well.
IIRC the reason I wanted something like this was for a demo where I use 
a proprietary library that only supports win32 and linux, and thus those 
two versions wants a single implementation, all other will not use it at 
all.

I realise this can be done with something like:

version(Windows) version=OK;
else version(linux) version=OK;
version(OK)
{
	...
}
else
{
	...
}

but just:

version(Windows || linux)
{
	...
}
else
{
	...
}

is clearer IMHO.
Nov 28 2006
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Tomas Lindquist Olsen wrote:

 Walter Bright wrote:

 Gregor Richards wrote:

     version (NOTWINDOWS) => version (LINUX)


 I hate to say this, but that example just plain stupid. All it will 
 ever do is limit your code to work on only certain operating systems. 
 That's hindering portability, and that's no good.

 As it turns out, it's often the case that such-and-such does work on 
 every sane operating system, and therefore version (!Windows) makes 
 sense.


 I've seen a lot of code that did that, and it was nearly always 
 broken. That's one motivation for operating system versions should be 
 positives, not "this is for not windows" or "this is for not linux". 
 Such fundamentally are wrong, and will bite you or the maintainer 
 sooner or later.


 I know I've ran into instances where $WEIRD_SOCKET_FEATURE_X crashes 
 horribly on a certain operating system, so I was forced to #ifndef 
 __APPLE__. The same feature worked fine on literally every other 
 system I tested it on, so it would be ridiculous to do an #ifdef for 
 everything BUT Apple.

 version (darwin)
 version (BSD)
 version (Solaris)
 version (SkyOS)
 version (DJGPP)
 version (HURD)
 version (ObscureOS)
 version (OSYetToBeInvented)


 What I'd do is have APPLE_SOCKET_BUG with the workaround, and the 
 default for the else. That way, you can search for the workarounds for 
 that bug, and they won't be confused with other apple features or 
 other apple bugs. Furthermore, if apple fixes that bug, you can update 
 your code much easier with a targeted update than if you painted the 
 entire apple os that way.

 It's common practice (such as in STL) to target specific bugs with 
 specific identifiers, and then have a configuration file which sets up 
 the bugs for each system.


 Thinking in positives is great, but so unrealistic as to be 
 completely valueless. version statements in reality are used like 
 indexes into sets. The set of operating systems, the set of C 
 libraries, the set of compielrs. And it's unrealistic and ignorant to 
 try to index EVERY member except for whichever one you like, 
 especially since the list is always growing.

 Not everything has a positive opposite. In fact, most everything 
 doesn't.


 I don't agree, and as an example I suggest the socket bug approach above.


 
 This discussion has made me remember something I though about a while 
 ago...
 While I understand the reasoning for disallowing negated version 
 identifiers / version statements from the above, I dont understand why 
 we can't use logical operators with versions:
 
 version(Windows)
 {
     writefln("I know your OS");
 }
 else version(linux)
 {
     writefln("I know your OS");
 }
 else version(darwin)
 {
     writefln("I know your OS");
 }
 else
 {
     writefln("I don't know your OS");
 }
 
 VS.
 
 version(Windows || linux || darwin)
 {
     writefln("I know your OS");
 }
 else
 {
     writefln("I don't know your OS");
 }
 
 This genuinely reduces code duplication and is thus according to 
 standard D mentality: less prone to be buggy, easier to maintain, and 
 faster to write.
 Though if something like this was to be allowed, && and ! probably 
 should be as well.
 IIRC the reason I wanted something like this was for a demo where I use 
 a proprietary library that only supports win32 and linux, and thus those 
 two versions wants a single implementation, all other will not use it at 
 all.
 
 I realise this can be done with something like:
 
 version(Windows) version=OK;
 else version(linux) version=OK;
 version(OK)
 {
     ...
 }
 else
 {
     ...
 }
 
 but just:
 
 version(Windows || linux)
 {
     ...
 }
 else
 {
     ...
 }
 
 is clearer IMHO.



Agreed.  'version' is basically just an emasculated special case of 
'static if'.  'static if' didn't exist when 'version' was created, but 
now that it does, I think it would make more sense if version became a 
kind of static if with access to a special version namespace.  'Windows' 
should be treated like an alias for true if it is indeed defined, 
otherwise false, and you should be allowed to do boolean ops with any 
constant values in your program inside the version statement.

--bb
Nov 28 2006
next sibling parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Bill Baxter wrote:

 
 Agreed.  'version' is basically just an emasculated special case of 
 'static if'.  'static if' didn't exist when 'version' was created, but 
 now that it does, I think it would make more sense if version became a 
 kind of static if with access to a special version namespace.  'Windows' 
 should be treated like an alias for true if it is indeed defined, 
 otherwise false, and you should be allowed to do boolean ops with any 
 constant values in your program inside the version statement.
 
 --bb


I dont think a version statement should be able to access anything but 
versions. besides that I agree!
Nov 28 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Tomas Lindquist Olsen wrote:

 Bill Baxter wrote:

 Agreed.  'version' is basically just an emasculated special case of 
 'static if'.  'static if' didn't exist when 'version' was created, but 
 now that it does, I think it would make more sense if version became a 
 kind of static if with access to a special version namespace.  
 'Windows' should be treated like an alias for true if it is indeed 
 defined, otherwise false, and you should be allowed to do boolean ops 
 with any constant values in your program inside the version statement.

 --bb


 
 I dont think a version statement should be able to access anything but 
 versions. besides that I agree!


I could agree with only versions in version statements, but if so then 
there needs to be a way to define new versions from code.

Walter's comment about defining versions for specific bugs is on target, 
but it makes no sense to have to specify every possible bug and 
workaround on the command line.  The common pattern used in most major 
cross-platform toolkits that deal with these issues is to have some sort 
of platform include that basically does things like:

#ifdef WINDOWS
#define BROKEN_PIPE_IMPLEMENTATION
#define BROKEN_SELECT_IMPLEMENTATION
...etc
#endif

If version acted like an enhanced static if then you could do something 
like:

version (Windows) {
    const int BROKEN_THIS = 1;
    const int BROKEN_THAT = 1;
    ...
}

version (BROKEN_THIS) {
    // workaround code
}

In that case I guess version(/undefined symbol/) should evaluate to false.

If you can't use const ints in version statements, then I think you 
really need to have something like:

defversion BROKEN_THIS;
defversion BROKEN_THAT;

And while we're talking about versions, there also needs to be a sane 
way to check if the version of the software you're using is greater than 
some minimum.

version(COOL_LIB_MAJOR_REV>4 || (COOL_LIB_MINOR_REV > 1)
{
}

or even better something special for version numbers like or

version(COOL_LIB_REV > [4, 1])

version(COOL_LIB_REV > 4.1.0)

Here's wxWidgets version macro for checking the version of wxWidgets 
you're compiling with.  It should be possible to get the same effect in 
D somehow:

/*  check if the current version is at least major.minor.release */
#define wxCHECK_VERSION(major,minor,release) \
     (wxMAJOR_VERSION > (major) || \
     (wxMAJOR_VERSION == (major) && wxMINOR_VERSION > (minor)) || \
     (wxMAJOR_VERSION == (major) && wxMINOR_VERSION == (minor) && 
wxRELEASE_NUMBER >= (release)))

Here's the full header that came from:  http://tinyurl.com/tzbom


Basically I think you can do all that with static if now.  If version 
doesn't get some more smarts then I'm betting people will use static if 
to accomplish things like the above since it's the only way.  And if 
people start using static if for version checks, well then what was the 
point of version, exactly?

--bb
Nov 28 2006
next sibling parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Bill Baxter wrote:

 Tomas Lindquist Olsen wrote:

 Bill Baxter wrote:

 Agreed.  'version' is basically just an emasculated special case of 
 'static if'.  'static if' didn't exist when 'version' was created, 
 but now that it does, I think it would make more sense if version 
 became a kind of static if with access to a special version 
 namespace.  'Windows' should be treated like an alias for true if it 
 is indeed defined, otherwise false, and you should be allowed to do 
 boolean ops with any constant values in your program inside the 
 version statement.

 --bb


 I dont think a version statement should be able to access anything but 
 versions. besides that I agree!


 
 I could agree with only versions in version statements, but if so then 
 there needs to be a way to define new versions from code.
 
 Walter's comment about defining versions for specific bugs is on target, 
 but it makes no sense to have to specify every possible bug and 
 workaround on the command line.  The common pattern used in most major 
 cross-platform toolkits that deal with these issues is to have some sort 
 of platform include that basically does things like:
 
 #ifdef WINDOWS
 #define BROKEN_PIPE_IMPLEMENTATION
 #define BROKEN_SELECT_IMPLEMENTATION
 ...etc
 #endif
 
 If version acted like an enhanced static if then you could do something 
 like:
 
 version (Windows) {
    const int BROKEN_THIS = 1;
    const int BROKEN_THAT = 1;
    ...
 }
 
 version (BROKEN_THIS) {
    // workaround code
 }
 
 In that case I guess version(/undefined symbol/) should evaluate to false.
 
 If you can't use const ints in version statements, then I think you 
 really need to have something like:
 
 defversion BROKEN_THIS;
 defversion BROKEN_THAT;
 
 And while we're talking about versions, there also needs to be a sane 
 way to check if the version of the software you're using is greater than 
 some minimum.
 
 version(COOL_LIB_MAJOR_REV>4 || (COOL_LIB_MINOR_REV > 1)
 {
 }
 
 or even better something special for version numbers like or
 
 version(COOL_LIB_REV > [4, 1])
 
 version(COOL_LIB_REV > 4.1.0)
 
 Here's wxWidgets version macro for checking the version of wxWidgets 
 you're compiling with.  It should be possible to get the same effect in 
 D somehow:
 
 /*  check if the current version is at least major.minor.release */
 #define wxCHECK_VERSION(major,minor,release) \
     (wxMAJOR_VERSION > (major) || \
     (wxMAJOR_VERSION == (major) && wxMINOR_VERSION > (minor)) || \
     (wxMAJOR_VERSION == (major) && wxMINOR_VERSION == (minor) && 
 wxRELEASE_NUMBER >= (release)))
 
 Here's the full header that came from:  http://tinyurl.com/tzbom
 
 
 Basically I think you can do all that with static if now.  If version 
 doesn't get some more smarts then I'm betting people will use static if 
 to accomplish things like the above since it's the only way.  And if 
 people start using static if for version checks, well then what was the 
 point of version, exactly?
 
 --bb


Read http://digitalmars.com/d/version.html#version : Version Specification
Nov 28 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Tomas Lindquist Olsen wrote:


 Read http://digitalmars.com/d/version.html#version : Version Specification


Thanks. :-)

But I don't see how I specify that I want MY_COOL_LIB_VER > 010205.
I can only say I want 'version' to be >= 010205.  But version of what?

For checking versions of specific libs , and for defining new versions 
contingent on existing versions, it still looks like I need a static if.

--bb
Nov 28 2006
parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Bill Baxter wrote:

 Tomas Lindquist Olsen wrote:
 

 Read http://digitalmars.com/d/version.html#version : Version 
 Specification


 
 Thanks. :-)
 
 But I don't see how I specify that I want MY_COOL_LIB_VER > 010205.
 I can only say I want 'version' to be >= 010205.  But version of what?
 
 For checking versions of specific libs , and for defining new versions 
 contingent on existing versions, it still looks like I need a static if.
 
 --bb


I really think you're leaving the scope of version now and entering 
if/static if
Nov 28 2006
parent Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tomas Lindquist Olsen schrieb am 2006-11-29:

 Bill Baxter wrote:

 Tomas Lindquist Olsen wrote:
 

 Read http://digitalmars.com/d/version.html#version : Version 
 Specification


 
 Thanks. :-)
 
 But I don't see how I specify that I want MY_COOL_LIB_VER > 010205.
 I can only say I want 'version' to be >= 010205.  But version of what?
 
 For checking versions of specific libs , and for defining new versions 
 contingent on existing versions, it still looks like I need a static if.
 
 --bb


 I really think you're leaving the scope of version now and entering 
 if/static if


You can combine both.

config.d:






some_code.d:








Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFFbUI8LK5blCcjpWoRAn5TAJ42e7sOSDHpp+ybDmicTm8Wyqc4DwCeLBcM
Q02laQLngiwKSzRn/EYjYMg=
=+DJ8
-----END PGP SIGNATURE-----
Nov 28 2006
prev sibling next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
 version (Windows) {
    const int BROKEN_THIS = 1;
    const int BROKEN_THAT = 1;
    ...
 }
 
 version (BROKEN_THIS) {
    // workaround code
 }


Try:

version (Windows) {
     version = BROKEN_THIS;
     version = BROKEN_THAT;
}

version (BROKEN_THIS) {
     // work around code
}
Nov 28 2006
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Brad Roberts wrote:

 version (Windows) {
    const int BROKEN_THIS = 1;
    const int BROKEN_THAT = 1;
    ...
 }

 version (BROKEN_THIS) {
    // workaround code
 }


 
 Try:
 
 version (Windows) {
     version = BROKEN_THIS;
     version = BROKEN_THAT;
 }
 
 version (BROKEN_THIS) {
     // work around code
 }


Doh, ok.  Missed that.  Cool.

What about the check for specific version of lib?

--bb
Nov 28 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Bill Baxter wrote:

 Here's wxWidgets version macro for checking the version of wxWidgets 
 you're compiling with.  It should be possible to get the same effect in 
 D somehow:
 
 /*  check if the current version is at least major.minor.release */
 #define wxCHECK_VERSION(major,minor,release) \
     (wxMAJOR_VERSION > (major) || \
     (wxMAJOR_VERSION == (major) && wxMINOR_VERSION > (minor)) || \
     (wxMAJOR_VERSION == (major) && wxMINOR_VERSION == (minor) && 
 wxRELEASE_NUMBER >= (release)))


To ask the obvious dumb question, why? If I was to see such, I'd wonder 
what purpose wxCHECK_VERSION was being used for. I presume it is to 
enable/disable certain things.

I suggest instead to either:

1) create version identifiers for those "certain things" like 
wxFEATURE_FOO_IS_WORKING

2) create an api for those features and abstract them into other modules

3) wxVERSION_NUMER already combines the values into one integer. Use 
that integer instead as the overall version number.
Nov 28 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:

 Bill Baxter wrote:

 Here's wxWidgets version macro for checking the version of wxWidgets 
 you're compiling with.  It should be possible to get the same effect 
 in D somehow:

 /*  check if the current version is at least major.minor.release */
 #define wxCHECK_VERSION(major,minor,release) \
     (wxMAJOR_VERSION > (major) || \
     (wxMAJOR_VERSION == (major) && wxMINOR_VERSION > (minor)) || \
     (wxMAJOR_VERSION == (major) && wxMINOR_VERSION == (minor) && 
 wxRELEASE_NUMBER >= (release)))


 
 To ask the obvious dumb question, why? If I was to see such, I'd wonder 
 what purpose wxCHECK_VERSION was being used for. I presume it is to 
 enable/disable certain things.
 
 I suggest instead to either:
 
 1) create version identifiers for those "certain things" like 
 wxFEATURE_FOO_IS_WORKING


That's great if the wx developers put that in for me, but if they didn't 
then the wx release number is the only info you have to determine if 
FEATURE_FOO_IS_WORKING.  So you'll end up with basically this in your 
"version features" module:

static if(wxCHECK_VERSION > 20603) {
    version = FEATURE_FOO_IS_WORKING
}

The need for checking against a version didn't go away, it just moved 
into the module.

If that's the way one is supposed to use 'version' then I'm ok doing 
that.  Just seems like both kinds of checks are about versions, so it 
should all be in a version() check, rather than some things static if(), 
some things version().


 
 2) create an api for those features and abstract them into other modules
 
 3) wxVERSION_NUMER already combines the values into one integer. Use 
 that integer instead as the overall version number.


--bb
Nov 29 2006
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bill Baxter wrote:


 The need for checking against a version didn't go away, it just moved 
 into the module.


Only problem is that you cannot import version statements from modules.

So all those version statements need to move to the command line, or to
an external tool like bu[il]d in order to have something like autoconf.

--anders
Nov 29 2006
parent reply "Chris Miller" <chris dprogramming.com> writes:
On Wed, 29 Nov 2006 03:26:58 -0500, Anders F Björklund <afb algonet.se>  
wrote:


 Bill Baxter wrote:


 The need for checking against a version didn't go away, it just moved  
 into the module.


 Only problem is that you cannot import version statements from modules.

 So all those version statements need to move to the command line, or to
 an external tool like bu[il]d in order to have something like autoconf.

 --anders


I like how D simplified this. It makes it much easier to do a general  
parse of a source file without having to follow imports (which can be a  
pain - e.g. several import dirs).

This is also why I like how `static if` and version are for different  
purposes and `static if` should not work at the module level.
Nov 29 2006
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Chris Miller wrote:


 I like how D simplified this. It makes it much easier to do a general  
 parse of a source file without having to follow imports (which can be a  
 pain - e.g. several import dirs).


Simpler for the parser, I guess. But harder for the user, unfortunately.
(since you have learn and make changes with more than one tool/language)
But once one gets the build system in place, it should be all good...
(i.e. instead of doing a config.h file, it can generate a commandline)

Probably only affects us weirdos not using "Windows" or "linux" anyway.

--anders
Nov 29 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Anders F Björklund wrote:

 Chris Miller wrote:
 

 I like how D simplified this. It makes it much easier to do a general  
 parse of a source file without having to follow imports (which can be 
 a  pain - e.g. several import dirs).


 
 Simpler for the parser, I guess. But harder for the user, unfortunately.
 (since you have learn and make changes with more than one tool/language)
 But once one gets the build system in place, it should be all good...
 (i.e. instead of doing a config.h file, it can generate a commandline)


I believe it is harder for the initial programmer, but much simpler for 
the maintenance programmer. Have you ever been faced with maintaining a 
piece of C code with complicated #if statements, and you have no idea if 
FOO is defined or not, or what it is #define'd to? You've got to look at 
the module, the freakin' command line, the makefile, the #include path, 
every freakin' #include file, which of course use more #if's to 
optionally #include other freakin' files, and such #defines are even 
created using freakin' complicated token pasting!

Not allowing versions from one module to affect imports of it is a major 
boon to maintenance and discoverability of the code. It requires 
rethinking of how to organize building multiple versions from the same 
source. The best way I've found is to abstract the version differences 
into an API, and then have the different implementations of those APIs 
in different modules.
Nov 29 2006
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Walter Bright wrote:


 I believe it is harder for the initial programmer, but much simpler for 
 the maintenance programmer. Have you ever been faced with maintaining a 
 piece of C code with complicated #if statements, and you have no idea if 
 FOO is defined or not, or what it is #define'd to? You've got to look at 
 the module, the freakin' command line, the makefile, the #include path, 
 every freakin' #include file, which of course use more #if's to 
 optionally #include other freakin' files, and such #defines are even 
 created using freakin' complicated token pasting!


Yes I have, but it also allows for writing very portable code.
I've also done Java code that did not have macro facilities,
so even if it only ran on a handful setups it still had to use
code generators or force a very specific setup upon everybody.

I'm sure that things would be different if writing new D code,
and not just porting C/C++ stuff over - which is where I usually
run into wanting a #ifndef or other similar predefined versions.
I don't *want* to change the macros, since they're in the API...


BTW: For compatibility with Windows (of wxD) I had to rewrite the sh 
scripts as programs, so now it should be working on Windows and Unix.
They will check the current setup, and output the -version/-fversion.
(it writes a text file or config.mak, to include into the Makefiles)
Not sure if it's easier there (compared to a module), but it works OK.
Latest version will even write the library pragmas for Build to use...
Will be good if you don't want to use the GNU toolchain (i.e. MinGW) ?
(as the original version just used wx-config/pkg-config and backticks)

--anders
Nov 29 2006
parent reply Sean Kelly <sean f4.ca> writes:
Anders F Björklund wrote:

 
 I'm sure that things would be different if writing new D code,
 and not just porting C/C++ stuff over - which is where I usually
 run into wanting a #ifndef or other similar predefined versions.
 I don't *want* to change the macros, since they're in the API...


Doesn't 'static if' fit the bill here?  It supports full expression 
logic and is evaluated at compile-time, just like 'version'.  In 
instances where code is automatically translated to D, I'd probably just 
convert #defines to enum or const values and use 'static if' in place of 
#if.  For manual conversions though, I think a hybrid approach is best. 
  For example, in converting POSIX headers to D I've noticed that nearly 
all the #if blocks are for selecting features determined at an OS 
level--the presence of conditions that may vary within an OS is actually 
pretty rare.  That being the case, it seems reasonable to either version 
by OS name or set up more granular version identifiers and pre-select 
the appropriate ones in a makefile or global compiler parameter variable.


Sean
Nov 29 2006
parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Sean Kelly wrote:


 I'm sure that things would be different if writing new D code,
 and not just porting C/C++ stuff over - which is where I usually
 run into wanting a #ifndef or other similar predefined versions.
 I don't *want* to change the macros, since they're in the API...


 
 Doesn't 'static if' fit the bill here?


It probably does. Just wasn't around when I started with D,
so I haven't really gotten used to using it instead... :-)

--anders
Nov 29 2006
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
Bill Baxter wrote:

 Walter Bright wrote:

 Bill Baxter wrote:

 Here's wxWidgets version macro for checking the version of wxWidgets 
 you're compiling with.  It should be possible to get the same effect 
 in D somehow:

 /*  check if the current version is at least major.minor.release */
 #define wxCHECK_VERSION(major,minor,release) \
     (wxMAJOR_VERSION > (major) || \
     (wxMAJOR_VERSION == (major) && wxMINOR_VERSION > (minor)) || \
     (wxMAJOR_VERSION == (major) && wxMINOR_VERSION == (minor) && 
 wxRELEASE_NUMBER >= (release)))


 To ask the obvious dumb question, why? If I was to see such, I'd 
 wonder what purpose wxCHECK_VERSION was being used for. I presume it 
 is to enable/disable certain things.

 I suggest instead to either:

 1) create version identifiers for those "certain things" like 
 wxFEATURE_FOO_IS_WORKING


 
 That's great if the wx developers put that in for me, but if they didn't 
 then the wx release number is the only info you have to determine if 
 FEATURE_FOO_IS_WORKING.  So you'll end up with basically this in your 
 "version features" module:
 
 static if(wxCHECK_VERSION > 20603) {
    version = FEATURE_FOO_IS_WORKING
 }
 
 The need for checking against a version didn't go away, it just moved 
 into the module.
 
 If that's the way one is supposed to use 'version' then I'm ok doing 
 that.  Just seems like both kinds of checks are about versions, so it 
 should all be in a version() check, rather than some things static if(), 
 some things version().
 

 2) create an api for those features and abstract them into other modules

 3) wxVERSION_NUMER already combines the values into one integer. Use 
 that integer instead as the overall version number.


 
 --bb


One thing I like about D is the opportunity to evaluate past mechanisms 
to see if they're the 'right' way of doing things.  Something about the 
use of specific feature flags rather than generic version number 
matching feels cleaner.  I do recognize that it makes porting of some 
existing blocks of code one notch harder.

Later,
Brad
Nov 29 2006
prev sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Bill Baxter wrote:

 Tomas Lindquist Olsen wrote:

 Walter Bright wrote:

 Gregor Richards wrote:

     version (NOTWINDOWS) => version (LINUX)


 I hate to say this, but that example just plain stupid. All it will 
 ever do is limit your code to work on only certain operating 
 systems. That's hindering portability, and that's no good.

 As it turns out, it's often the case that such-and-such does work on 
 every sane operating system, and therefore version (!Windows) makes 
 sense.


 I've seen a lot of code that did that, and it was nearly always 
 broken. That's one motivation for operating system versions should be 
 positives, not "this is for not windows" or "this is for not linux". 
 Such fundamentally are wrong, and will bite you or the maintainer 
 sooner or later.


 I know I've ran into instances where $WEIRD_SOCKET_FEATURE_X crashes 
 horribly on a certain operating system, so I was forced to #ifndef 
 __APPLE__. The same feature worked fine on literally every other 
 system I tested it on, so it would be ridiculous to do an #ifdef for 
 everything BUT Apple.

 version (darwin)
 version (BSD)
 version (Solaris)
 version (SkyOS)
 version (DJGPP)
 version (HURD)
 version (ObscureOS)
 version (OSYetToBeInvented)


 What I'd do is have APPLE_SOCKET_BUG with the workaround, and the 
 default for the else. That way, you can search for the workarounds 
 for that bug, and they won't be confused with other apple features or 
 other apple bugs. Furthermore, if apple fixes that bug, you can 
 update your code much easier with a targeted update than if you 
 painted the entire apple os that way.

 It's common practice (such as in STL) to target specific bugs with 
 specific identifiers, and then have a configuration file which sets 
 up the bugs for each system.


 Thinking in positives is great, but so unrealistic as to be 
 completely valueless. version statements in reality are used like 
 indexes into sets. The set of operating systems, the set of C 
 libraries, the set of compielrs. And it's unrealistic and ignorant 
 to try to index EVERY member except for whichever one you like, 
 especially since the list is always growing.

 Not everything has a positive opposite. In fact, most everything 
 doesn't.


 I don't agree, and as an example I suggest the socket bug approach 
 above.


 This discussion has made me remember something I though about a while 
 ago...
 While I understand the reasoning for disallowing negated version 
 identifiers / version statements from the above, I dont understand why 
 we can't use logical operators with versions:

 version(Windows)
 {
     writefln("I know your OS");
 }
 else version(linux)
 {
     writefln("I know your OS");
 }
 else version(darwin)
 {
     writefln("I know your OS");
 }
 else
 {
     writefln("I don't know your OS");
 }

 VS.

 version(Windows || linux || darwin)
 {
     writefln("I know your OS");
 }
 else
 {
     writefln("I don't know your OS");
 }

 This genuinely reduces code duplication and is thus according to 
 standard D mentality: less prone to be buggy, easier to maintain, and 
 faster to write.
 Though if something like this was to be allowed, && and ! probably 
 should be as well.
 IIRC the reason I wanted something like this was for a demo where I 
 use a proprietary library that only supports win32 and linux, and thus 
 those two versions wants a single implementation, all other will not 
 use it at all.

 I realise this can be done with something like:

 version(Windows) version=OK;
 else version(linux) version=OK;
 version(OK)
 {
     ...
 }
 else
 {
     ...
 }

 but just:

 version(Windows || linux)
 {
     ...
 }
 else
 {
     ...
 }

 is clearer IMHO.


 
 
 Agreed.  'version' is basically just an emasculated special case of 
 'static if'.  'static if' didn't exist when 'version' was created, but 
 now that it does, I think it would make more sense if version became a 
 kind of static if with access to a special version namespace.  'Windows' 
 should be treated like an alias for true if it is indeed defined, 
 otherwise false, and you should be allowed to do boolean ops with any 
 constant values in your program inside the version statement.
 
 --bb


I know we've been over this before, but the suggested syntax is clearly 
more elegant than the current use. Could you specify any particular 
reason why these operators shouldn't be allowed in this manner?

However, I also dont agree that anything other than Versions should work 
inside of version() expressions.
Nov 28 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Tomas Lindquist Olsen wrote:

 version(Windows || linux)
 {
     ...
 }
 else
 {
     ...
 }
 
 is clearer IMHO.


That is certainly seductive and it's hard to see what's wrong with it. 
But I've seen what it inevitably leads to - an ugly, incomprehensible 
mess that is invariably wrong. It's often so bad that I have to run the 
preprocessor just to figure out which pieces of the code are actually 
being compiled! I haven't seen one yet that couldn't stand being 
reevaluated.

If you find wanting && and || and ?: and ! in the versions, I suggest 
one the following:

1) reevaluate just what feature it is you're testing for, and create a 
version identifier for that feature.

2) abstract the version differences away in a separate module.

Sure, it requires a little more work and a little more thought. But I 
think it's worth it, it's certainly been so when I've used that approach.
Nov 28 2006
parent Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:

 Tomas Lindquist Olsen wrote:
 

 version(Windows || linux)
 {
     ...
 }
 else
 {
     ...
 }

 is clearer IMHO.


 
 
 That is certainly seductive and it's hard to see what's wrong with it. 
 But I've seen what it inevitably leads to - an ugly, incomprehensible 
 mess that is invariably wrong. It's often so bad that I have to run the 
 preprocessor just to figure out which pieces of the code are actually 
 being compiled! I haven't seen one yet that couldn't stand being 
 reevaluated.
 
 If you find wanting && and || and ?: and ! in the versions, I suggest 
 one the following:
 
 1) reevaluate just what feature it is you're testing for, and create a 
 version identifier for that feature.
 
 2) abstract the version differences away in a separate module.
 
 Sure, it requires a little more work and a little more thought. But I 
 think it's worth it, it's certainly been so when I've used that approach.


Sometimes a common problem suggests a solution so that everybody in the 
audience invents more or less the same thing. When it doesn't seem to 
have immediate downsides, there'll be unanimous demand for it.

If the man on the stage doesn't shoot down the solution vigorously 
enough, there will eventually be a riot demanding implementation.

At the end of the day, only historians will eventually sort out who was 
right each time.

---

This compiling conditionals issue, IMHO, is what Walter really has been 
doing all his life. And such Experience is invaluable when the downsides 
are not obvious enough to even seasoned programmers. In one sense, 
that's the whole point of demanding experience when hiring people.
Nov 29 2006
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:

 Gregor Richards wrote:

     version (NOTWINDOWS) => version (LINUX)


 I hate to say this, but that example just plain stupid. All it will 
 ever do is limit your code to work on only certain operating systems. 
 That's hindering portability, and that's no good.

 As it turns out, it's often the case that such-and-such does work on 
 every sane operating system, and therefore version (!Windows) makes 
 sense.


 
 I've seen a lot of code that did that, and it was nearly always broken. 
 That's one motivation for operating system versions should be positives, 
 not "this is for not windows" or "this is for not linux". Such 
 fundamentally are wrong, and will bite you or the maintainer sooner or 
 later.


There's a horrible effect in C++ Windows where there's lots of code 
which has #ifdef __MSVC__, even though it works on many other compilers.
So vendors like CodePlay and Metrowerks fraudulently define __MSVC__.
I hope we can avoid this in D.
I've already seen some uses of
DigitalMars_Inline_Asm
because GDC doesn't support the full set of x86 opcodes. I think failure 
to implement the spec should always be tested with a positive. Certainly 
code should never have a list of compilers which meet the spec!

And if a vendor knows that they're not implementing part of the spec, 
they should provide an identifier indicating that fact. That way, the 
vendor can fix the problem without breaking existing code.
Dec 01 2006
parent Walter Bright <newshound digitalmars.com> writes:
Don Clugston wrote:

 There's a horrible effect in C++ Windows where there's lots of code 
 which has #ifdef __MSVC__, even though it works on many other compilers.
 So vendors like CodePlay and Metrowerks fraudulently define __MSVC__.


That's just the start. I often find #ifdef WINDOWS when it's a compiler 
dependency, not a Windows dependency. Same for linux/__GNUC__


 I hope we can avoid this in D.


So do I.


 I've already seen some uses of
 DigitalMars_Inline_Asm
 because GDC doesn't support the full set of x86 opcodes. I think failure 
 to implement the spec should always be tested with a positive. Certainly 
 code should never have a list of compilers which meet the spec!
 
 And if a vendor knows that they're not implementing part of the spec, 
 they should provide an identifier indicating that fact. That way, the 
 vendor can fix the problem without breaking existing code.


Yes.
Dec 01 2006
prev sibling next sibling parent Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Bill Baxter wrote:

 
 Ok, why don't you go ahead and ask "admin AT dsource DOT org" for a 
 WinMin page?
 


I have posted in the potential projects forum at dsource.

http://dsource.org/forums/viewtopic.php?t=2081
Nov 28 2006
prev sibling parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Bill Baxter wrote:

 
 Looks interesting.  Thanks for the link.  The one thing I was most 
 curious about was whether it uses emulation or wrapping of native 
 widgets.  But I can't find that mentioned anywhere.  All the screen 
 shots seem to show a winXP kind of look and some clearly non-native 
 widgets (like the color picker), so I'm thinking it's emulated with 
 winXP look everywhere?  Is it themeable?
 
 Whoa, though, that QTF is crazy!
 http://www.ultimatepp.org/srcdoc$RichText$QTF$en-us.html
 "WTF" is more what comes to mind... it seems so out of place in a 
 toolkit that puts a priority on simplicity and clarity.
 
 They should make T-Shirts:
   Got "{{1:2 A1::l40/60R6 3 A2::! B1:: B2}}"?
 



Ultimate++ is a window less GUI toolkit. Everything is written from 
"scratch" and only the TopWindow has a native handle. They are working 
on skinning in the latest dev releases (which btw have some nice 
features and are pretty stable).

Harmonia seems to do some of the same things Ultimate++ does.

And yeah QTF is insane :P
Nov 28 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Tomas Lindquist Olsen wrote:

 Bill Baxter wrote:

 Looks interesting.  Thanks for the link.  The one thing I was most 
 curious about was whether it uses emulation or wrapping of native 
 widgets.  But I can't find that mentioned anywhere.  All the screen 
 shots seem to show a winXP kind of look and some clearly non-native 
 widgets (like the color picker), so I'm thinking it's emulated with 
 winXP look everywhere?  Is it themeable?

 Whoa, though, that QTF is crazy!
 http://www.ultimatepp.org/srcdoc$RichText$QTF$en-us.html
 "WTF" is more what comes to mind... it seems so out of place in a 
 toolkit that puts a priority on simplicity and clarity.

 They should make T-Shirts:
   Got "{{1:2 A1::l40/60R6 3 A2::! B1:: B2}}"?


 
 
 Ultimate++ is a window less GUI toolkit. Everything is written from 
 "scratch" and only the TopWindow has a native handle. They are working 
 on skinning in the latest dev releases (which btw have some nice 
 features and are pretty stable).


Thanks.  I think both approaches have merit.  Sometimes you really just 
want to make a custom widget that draws itself and will work immediately 
on every platform (then emulation==good).  But other times you really 
want to have the native look-and-feel (then wrapping==good).  Other 
times you just want to have a consistent look or theme across all 
platforms (then emulation==good).  But some particular things like file 
dialogs tend to easier on users if they are native (then wrapping==good).


 Harmonia seems to do some of the same things Ultimate++ does.


Harmonia seems an interesting beastie.  Not quite my cup of tea, but 
some interesting ideas there to be sure.


 And yeah QTF is insane :P


The only thing I can figure is that Ultimate++ must have been created by 
some BBS hackers who wrote ANSI graphics in their sleep back in the day.

--bb
Nov 28 2006
parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Bill Baxter wrote:

 Tomas Lindquist Olsen wrote:

 Ultimate++ is a window less GUI toolkit. Everything is written from
 "scratch" and only the TopWindow has a native handle. They are working
 on skinning in the latest dev releases (which btw have some nice
 features and are pretty stable).


 
 Thanks.  I think both approaches have merit.  Sometimes you really just
 want to make a custom widget that draws itself and will work immediately
 on every platform (then emulation==good).  But other times you really
 want to have the native look-and-feel (then wrapping==good).  Other
 times you just want to have a consistent look or theme across all
 platforms (then emulation==good).  But some particular things like file
 dialogs tend to easier on users if they are native (then wrapping==good).


Some platforms don't have one native look-and-feel. On one of my Linux
desktops I have quite equal amount of programs written in 7 different
toolkits: fltk, gtk+ 1 and 2, qt, motif, swing and custom toolkits (e.g.
blender). Then, of course there are also those ugly plain X apps, but
does anyone really use them. Luckily the fltk & gtk+ 1 -programs are
some day "upgrading" their toolkits to some more common one. For example
XMMS is being replaced by BMP and Audacious.

Then there are those less common desktop environments that have pretty
minimalistic native toolkits.

I just hope that one day someone makes a general purpose toolkit for all
the environments and for all kinds of users. And with the help of
metaprogramming it just might be possible to create that without too
much bloat. A great potential killer app for D. :)
Dec 03 2006
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Jari-Matti Mäkelä wrote:

 Bill Baxter wrote:

 Tomas Lindquist Olsen wrote:





 Some platforms don't have one native look-and-feel. On one of my Linux
 desktops I have quite equal amount of programs written in 7 different
 toolkits: fltk, gtk+ 1 and 2, qt, motif, swing and custom toolkits (e.g.
 blender). Then, of course there are also those ugly plain X apps, but
 does anyone really use them. 


xfig!!


 Luckily the fltk & gtk+ 1 -programs are
 some day "upgrading" their toolkits to some more common one. For example
 XMMS is being replaced by BMP and Audacious.
 
 Then there are those less common desktop environments that have pretty
 minimalistic native toolkits.
 
 I just hope that one day someone makes a general purpose toolkit for all
 the environments and for all kinds of users. And with the help of
 metaprogramming it just might be possible to create that without too
 much bloat. A great potential killer app for D. :)


Software that sets out with the goal of being the right tool for 
everybody is usually delivered late (if at all), and ends up satisfying 
nobody.

--bb
Dec 03 2006
prev sibling next sibling parent Gregor Richards <Richards codu.org> writes:
Tomas Lindquist Olsen wrote:

 Hi folks.
 Just want to tell people that I have uploaded a zip with a MinWin that 
 builds on DMD 0.175.
 
 Check it at:
 http://wiki.dprogramming.com/MinWin/HomePage
 
 it only really took fixing the private/public import changes but it was 
 boring and I figure someone else might like to avoid it...
 
 - lindquist


To whom it may concern:

MinWin is now installable via DSSS.

$ dsss net install minwin

It's another great example of how to use pkg-config to generate link 
pragmas, as well.

Enjoy.

  - Gregor Richards
Nov 28 2006
prev sibling next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Tomas Lindquist Olsen wrote:


 Just want to tell people that I have uploaded a zip with a MinWin that 
 builds on DMD 0.175.
 
 Check it at:
 http://wiki.dprogramming.com/MinWin/HomePage
 
 it only really took fixing the private/public import changes but it was 
 boring and I figure someone else might like to avoid it...


With a few changes, it also built on Motif/GDC:
http://www.algonet.se/~afb/d/minwin-motif.patch

As usual I had no luck in getting bu[il]d to run,
so I ended up just running the commands directly...
Didn't have any Imlib either, so I versioned it out.
But besides that, it is looking as "lovely" as ever:
http://www.algonet.se/~afb/d/minwin-motif.png

There was a minor minwin Carbon port started earlier,
but it got halted - in favor of just using wxWidgets.
But if someone did a new OpenGL peer for minwin, then
Mac OS X could use that instead of X11.app and Motif.

--anders
Nov 28 2006
prev sibling next sibling parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Tomas Lindquist Olsen wrote:

 Hi folks.
 Just want to tell people that I have uploaded a zip with a MinWin that 
 builds on DMD 0.175.
 
 Check it at:
 http://wiki.dprogramming.com/MinWin/HomePage
 
 it only really took fixing the private/public import changes but it was 
 boring and I figure someone else might like to avoid it...
 
 - lindquist


For those that dont read the dsource forums, Brad has set up a SVN 
repository [1] and Trac environment [2] for MinWin and given me admin 
rights.

I have committed the version I posted to SVN with Anders's patch applied.

Lets get MinWin back on track :)

If there's anything let me know. I wont be the most active developer 
from day 1, I still need to read alot of the source + understand it, 
etc, but I will do my best to administer the project. At least now it 
can move on...

------------------------

[1] : http://svn.dsource.org/projects/minwin/trunk/minwin
[2] : http://www.dsource.org/projects/minwin/wiki
Nov 28 2006
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Tomas Lindquist Olsen wrote:


 For those that dont read the dsource forums, Brad has set up a SVN 
 repository [1] and Trac environment [2] for MinWin and given me admin 
 rights.
 
 I have committed the version I posted to SVN with Anders's patch applied.
 
 Lets get MinWin back on track :)


If you really want to try minwin out running on Mac OS X,
you first need Motif/LessTif and X11. And some hack like
mine: http://www.algonet.se/~afb/d/minwin-darwin.patch
(or you'll need to get the Imlib library going yourself)

Then (I guess) it should be something along the lines of:
bud  motif.brf

If you have MacPorts installed, you would probably prefer
using the GTK+ for X11 port from there instead of Motif...
And if you're really bored, you could try a Carbon port ?
(see http://developer.apple.com/referencelibrary/Carbon/)

--anders
Nov 29 2006
prev sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
Tomas Lindquist Olsen wrote:


 I have committed the version I posted to SVN with Anders's patch applied.
 
 Lets get MinWin back on track :)


Great!


 If there's anything let me know. I wont be the most active developer 
 from day 1, I still need to read alot of the source + understand it, 
 etc, but I will do my best to administer the project. At least now it 
 can move on...


DSource seems to be down at the moment, but I notice from the source I 
downloaded from your site that the implementation of MultiDelegate, used 
for notifications in the library, is ripe for Tuple-fication.  Lot's o 
templates there overloaded on number of arguments.

--bb
Nov 29 2006
parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Bill Baxter wrote:

 DSource seems to be down at the moment, but I notice from the source I 
 downloaded from your site that the implementation of MultiDelegate, used 
 for notifications in the library, is ripe for Tuple-fication.  Lot's o 
 templates there overloaded on number of arguments.
 
 --bb


Yup I noticed that as well, and SVN trunk now uses variadic templates
Nov 30 2006
parent Bill Baxter <wbaxter gmail.com> writes:
Tomas Lindquist Olsen wrote:

 Bill Baxter wrote:
 

 DSource seems to be down at the moment, but I notice from the source I 
 downloaded from your site that the implementation of MultiDelegate, 
 used for notifications in the library, is ripe for Tuple-fication.  
 Lot's o templates there overloaded on number of arguments.

 --bb


 
 
 Yup I noticed that as well, and SVN trunk now uses variadic templates


Cool.

Probably worth discussing whether MultiDelegate is the right way to do 
it, considering how similar it is to std.signals.Signal.

It seems to lack the safe disconnection mechanism in Signal.
But it adds a boolean return value.

--bb
Nov 30 2006
prev sibling parent reply "Tomas Lindquist Olsen" <tomas famolsen.dk> writes:
I've been looking at unicode support for MinWin in Windows.

From minwin/todo:
* mswindows
 - A vs W for string inputs - convert to wchar

It seems that sticking with char[] and only doing the toUTF16z
conversions under the hood is the most feasible.

I have attached a patch (made with tortoiseSVN) that makes
minwin/button.d work with unicode. It adds a few W functions to
minwin/mswindows.d as well.

Is there a better way?
Feedback is much appreciated, I think MinWin should support unicode
properly, and it's not that much work with this approach.

Does unicode work with GTK/Motif?

-- Tomas
Nov 30 2006
parent reply "Tomas Lindquist Olsen" <tomas famolsen.dk> writes:
Tomas Lindquist Olsen wrote:


 I've been looking at unicode support for MinWin in Windows.
 
 From minwin/todo:
 * mswindows
  - A vs W for string inputs - convert to wchar
 
 It seems that sticking with char[] and only doing the toUTF16z
 conversions under the hood is the most feasible.
 
 I have attached a patch (made with tortoiseSVN) that makes
 minwin/button.d work with unicode. It adds a few W functions to
 minwin/mswindows.d as well.
 
 Is there a better way?
 Feedback is much appreciated, I think MinWin should support unicode
 properly, and it's not that much work with this approach.
 
 Does unicode work with GTK/Motif?
 
 -- Tomas


Not sure whether the MinWin forum or this newsgroup is the right place
for the discussion, but I'm looking for feedback on this:

http://www.dsource.org/forums/viewtopic.php?t=2096

-- Tomas
Dec 02 2006
parent reply Bill Baxter <wbaxter gmail.com> writes:
Tomas Lindquist Olsen wrote:

 Tomas Lindquist Olsen wrote:
 
 

I've been looking at unicode support for MinWin in Windows.

From minwin/todo:
* mswindows
 - A vs W for string inputs - convert to wchar

It seems that sticking with char[] and only doing the toUTF16z
conversions under the hood is the most feasible.

I have attached a patch (made with tortoiseSVN) that makes
minwin/button.d work with unicode. It adds a few W functions to
minwin/mswindows.d as well.

Is there a better way?
Feedback is much appreciated, I think MinWin should support unicode
properly, and it's not that much work with this approach.

Does unicode work with GTK/Motif?

-- Tomas


 
 
 Not sure whether the MinWin forum or this newsgroup is the right place
 for the discussion, but I'm looking for feedback on this:
 
 http://www.dsource.org/forums/viewtopic.php?t=2096
 
 -- Tomas
 


Do you care about Win95?  If so then I recall there are some limitations 
to using unicode there, and you need something called unicows.dll to 
make it work at all.  I think unicows only supports a subset of the 
win32 api.

Personally I don't care about Win95, but apparently a lot of people 
still do.

If you don't care about Win95, then I believe you're right that the -W 
functions are the way to go.

[btw I'm not a big fan of forums... but I also realize it doesn't make 
sense to have dozens of project-specific threads going on here -- 
especially when 'here' is the "announce" newsgroup ;-)  Can DSource host 
mailing lists?  Could Walter host project-specific newsgroups?]

--bb
Dec 02 2006
parent reply "Chris Miller" <chris dprogramming.com> writes:
 Do you care about Win95?  If so then I recall there are some limitations  
 to using unicode there, and you need something called unicows.dll to  
 make it work at all.  I think unicows only supports a subset of the  
 win32 api.

 Personally I don't care about Win95, but apparently a lot of people  
 still do.

 If you don't care about Win95, then I believe you're right that the -W  
 functions are the way to go.


It also applies to Windows 95 and ME, which I believe still have a chunk  
of users. MSLU is an option but is a dependency.
Dec 02 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Chris Miller wrote:

 Do you care about Win95?  If so then I recall there are some 
 limitations to using unicode there, and you need something called 
 unicows.dll to make it work at all.  I think unicows only supports a 
 subset of the win32 api.

 Personally I don't care about Win95, but apparently a lot of people 
 still do.

 If you don't care about Win95, then I believe you're right that the -W 
 functions are the way to go.


 
 It also applies to Windows 95 and ME, which I believe still have a chunk 
 of users. MSLU is an option but is a dependency.


Don't use MSLU to support 95 and ME. Look into how std.file does it, 
that's the right way for D.
Dec 02 2006
next sibling parent "Tomas Lindquist Olsen" <tomas famolsen.dk> writes:
Walter Bright wrote:

 
 Don't use MSLU to support 95 and ME. Look into how std.file does it,
 that's the right way for D.


Thanx for the tip Walter.

I'm redoing the patch this way. With a few wrappers though or the code
gets very ugly...

--
Dec 02 2006
prev sibling next sibling parent reply "Chris Miller" <chris dprogramming.com> writes:
On Sat, 02 Dec 2006 20:09:41 -0500, Walter Bright  
<newshound digitalmars.com> wrote:


 Chris Miller wrote:

 Do you care about Win95?  If so then I recall there are some  
 limitations to using unicode there, and you need something called  
 unicows.dll to make it work at all.  I think unicows only supports a  
 subset of the win32 api.

 Personally I don't care about Win95, but apparently a lot of people  
 still do.

 If you don't care about Win95, then I believe you're right that the -W  
 functions are the way to go.


  It also applies to Windows 95 and ME, which I believe still have a  
 chunk of users. MSLU is an option but is a dependency.


 Don't use MSLU to support 95 and ME. Look into how std.file does it,  
 that's the right way for D.


I meant to say 98 and ME, and I agree that how std.file does it is better,  
it's how I usually do it, e.g. in DFL. However, if a library has less  
interest in supporting win9x/ME, and more interest in simplifying unicode,  
it may be easier to just use MSLU, even though I personally probably still  
wouldn't, but it's still an option.
Dec 02 2006
parent Walter Bright <newshound digitalmars.com> writes:
Chris Miller wrote:

 I meant to say 98 and ME, and I agree that how std.file does it is 
 better, it's how I usually do it, e.g. in DFL. However, if a library has 
 less interest in supporting win9x/ME, and more interest in simplifying 
 unicode, it may be easier to just use MSLU, even though I personally 
 probably still wouldn't, but it's still an option.


It's an option, but a poor one. MSLU doesn't actually add unicode 
support. It just provides translations just like std.file does. And 
worse, it requires you to ship the MSLU dll with your product, which 
makes it a nuisance for customers.
Dec 02 2006
prev sibling parent reply "Tomas Lindquist Olsen" <tomas famolsen.dk> writes:
Walter Bright wrote:


 Chris Miller wrote:

 Do you care about Win95?  If so then I recall there are some
 limitations to using unicode there, and you need something called
 unicows.dll to make it work at all.  I think unicows only
 supports a  subset of the win32 api.
 
 Personally I don't care about Win95, but apparently a lot of
 people  still do.
 
 If you don't care about Win95, then I believe you're right that
 the -W  functions are the way to go.


 
 It also applies to Windows 95 and ME, which I believe still have a
 chunk  of users. MSLU is an option but is a dependency.


 
 Don't use MSLU to support 95 and ME. Look into how std.file does it,
 that's the right way for D.


I have committed the Unicode update for Windows to SVN :)
Thanx again for pointing out how it should be done!

--
Dec 02 2006
parent reply Bill Baxter <wbaxter gmail.com> writes:
Tomas Lindquist Olsen wrote:

 Walter Bright wrote:
 
 

Chris Miller wrote:


Do you care about Win95?  If so then I recall there are some
limitations to using unicode there, and you need something called
unicows.dll to make it work at all.  I think unicows only
supports a  subset of the win32 api.

Personally I don't care about Win95, but apparently a lot of
people  still do.

If you don't care about Win95, then I believe you're right that
the -W  functions are the way to go.


It also applies to Windows 95 and ME, which I believe still have a
chunk  of users. MSLU is an option but is a dependency.


Don't use MSLU to support 95 and ME. Look into how std.file does it,
that's the right way for D.


 
 
 I have committed the Unicode update for Windows to SVN :)
 Thanx again for pointing out how it should be done!
 


And I can confirm that Japanese works now!  Yea!
  (though without in-place IME support, but that's a separate kettle o fish)

--bb
Dec 02 2006
parent reply "Tomas Lindquist Olsen" <tomas famolsen.dk> writes:
Bill Baxter wrote:


 Tomas Lindquist Olsen wrote:

 Walter Bright wrote:
 
 

 Chris Miller wrote:
 

 Do you care about Win95?  If so then I recall there are some
 limitations to using unicode there, and you need something
 called unicows.dll to make it work at all.  I think unicows
 only supports a  subset of the win32 api.
 
 Personally I don't care about Win95, but apparently a lot of
 people  still do.
 
 If you don't care about Win95, then I believe you're right
 that the -W  functions are the way to go.


 
 It also applies to Windows 95 and ME, which I believe still
 have a chunk  of users. MSLU is an option but is a dependency.


 
 Don't use MSLU to support 95 and ME. Look into how std.file does
 it, that's the right way for D.


 
 
 I have committed the Unicode update for Windows to SVN :)
 Thanx again for pointing out how it should be done!
 


 
 And I can confirm that Japanese works now!  Yea!
  (though without in-place IME support, but that's a separate kettle o
 fish)
 
 --bb


I have never heard of that IME.
Danish works fine.
If you know something that I can do to fix this please let me know!

And thanx for testing :)

--
Dec 03 2006
parent Bill Baxter <wbaxter gmail.com> writes:
Tomas Lindquist Olsen wrote:

 Bill Baxter wrote:
 
 

Tomas Lindquist Olsen wrote:


Walter Bright wrote:




Chris Miller wrote:



Do you care about Win95?  If so then I recall there are some
limitations to using unicode there, and you need something
called unicows.dll to make it work at all.  I think unicows
only supports a  subset of the win32 api.

Personally I don't care about Win95, but apparently a lot of
people  still do.

If you don't care about Win95, then I believe you're right
that the -W  functions are the way to go.


It also applies to Windows 95 and ME, which I believe still
have a chunk  of users. MSLU is an option but is a dependency.


Don't use MSLU to support 95 and ME. Look into how std.file does
it, that's the right way for D.



I have committed the Unicode update for Windows to SVN :)
Thanx again for pointing out how it should be done!


And I can confirm that Japanese works now!  Yea!
 (though without in-place IME support, but that's a separate kettle o
fish)

--bb


 
 
 I have never heard of that IME.
 Danish works fine.
 If you know something that I can do to fix this please let me know!
 
 And thanx for testing :)


After some experimentation, it looks like you need to use the RichEdit 
text control (2.0 or greater) to be able to do inline IME conversion.

The annoying thing about that is apparently you have to load the 
RichEdit dll yourself.  See what wxWidgets does here:

http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/src/msw/textctrl.cpp?rev=1.279&content-type=text/vnd.viewcvs-markup

General info about MSW rich edit controls:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/richedit/richeditcontrols/aboutricheditcontrols.asp

My feeling is that if MinWin is only going to offer one flavor of text 
control, it would be best for it to use the RichText control since it 
has all-around more functionality.

On the other hand I notice that even on Japanese Windows things like the 
Win+R run dialog use the plain "Edit" control and do not have in-place 
IME support.  Perhaps the best idea would be to use the simple "Edit" 
control for one-line text and the RichEdit control for multi-line text.

--bb
Dec 03 2006