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



 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 (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)

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)

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)

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

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

if/static if

You can combine both. config.d: # # version(Windows){ # const int WAPI_FEATURE = 3; # } # some_code.d: # # import config; # # static if(is(typeof(WAPI_FEATURE)) && WAPI_FEATURE == 3){ # // ... # } # Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFFbUI8LK5blCcjpWoRAn5TAJ42e7sOSDHpp+ybDmicTm8Wyqc4DwCeLBcM Q02laQLngiwKSzRn/EYjYMg= =+DJ8 -----END PGP SIGNATURE-----
Nov 28 2006
prev sibling next sibling 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
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 Kyle Furlong <kylefurlong gmail.com> writes:
Bill Baxter wrote:
 Tomas Lindquist Olsen wrote:
 Walter Bright wrote:
 Gregor Richards wrote:
     version (NOTWINDOWS) => version (LINUX)

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)

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 next sibling parent 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
prev sibling next 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 reply "Tomas Lindquist Olsen" <tomas famolsen.dk> writes:
This is a multipart message in MIME format

--Xananews.1.2.3

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


--Xananews.1.2.3
Content-Type: Application/Octet-Stream; name=minwin_unicode_button.patch
Content-Transfer-Encoding: base64

SW5kZXg6IGJ1dHRvbi5kDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09DQotLS0gYnV0dG9uLmQJKHJldmlzaW9uIDUpDQor
KysgYnV0dG9uLmQJKHdvcmtpbmcgY29weSkNCkBAIC04NSw2ICs4NSw3IEBADQogCiB2ZXJzaW9u
IChXaW5kb3dzKSB7CiAgIHByaXZhdGUgaW1wb3J0IG1pbndpbi5tc3dpbmRvd3M7CisgIHByaXZh
dGUgaW1wb3J0IHN0ZC51dGY7CiAKICAgY29uc3QgaW50IEJ1dHRvbkNsaWNrZWRDb21tYW5kID0g
Qk5fQ0xJQ0tFRDsKIApAQCAtOTgsMTMgKzk5LDE0IEBADQogCUZvbnQgZiA9IHN0YW5kYXJkRm9u
dChTdGFuZGFyZEZvbnQuR3VpKTsKIAlIRk9OVCBvbGRmb250ID0gU2VsZWN0T2JqZWN0KGRjLGYu
cGVlcik7CiAJc3lzQXNzZXJ0KG9sZGZvbnQgIWlzIG51bGwsICJGYWlsZWQgdG8gZ2V0IEJ1dHRv
biBmb250IGluIHByZWZlcnJlZFNpemUiKTsKLQlCT09MIHN0YXR1cyA9IEdldFRleHRFeHRlbnRQ
b2ludDMyQShkYyx0ZXh0X2RhdGEucHRyLHRleHRfZGF0YS5sZW5ndGgsJnMpOworCXdjaGFyW10g
d3RleHRfZGF0YSA9IHRvVVRGMTYodGV4dF9kYXRhKTsKKwlCT09MIHN0YXR1cyA9IEdldFRleHRF
eHRlbnRQb2ludDMyVyhkYyx3dGV4dF9kYXRhLnB0cix3dGV4dF9kYXRhLmxlbmd0aCwmcyk7CiAJ
U2VsZWN0T2JqZWN0KGRjLG9sZGZvbnQpOwogCXN5c0Fzc2VydChzdGF0dXMgIT0gZmFsc2UsICJG
YWlsZWQgdG8gZ2V0IGZvbnQgZXh0ZW50cyBpbiBwcmVmZXJyZWRTaXplIik7CiAgICAgICB9IGZp
bmFsbHkgewogCVJlbGVhc2VEQyhwZWVyLGRjKTsKICAgICAgIH0KLSAgICAgIHdpZHRoID0gcy5j
eCA+IDc1ID8gcy5jeCA6IDc1OworICAgICAgd2lkdGggPSBzLmN4ID4gNjMgPyBzLmN4KzEyIDog
NzU7CiAgICAgICBoZWlnaHQgPSBzLmN5ID4gMjMgPyBzLmN5IDogMjM7CiAgICAgICBpZiAodXNl
clByZWZlcnJlZFdpZHRoX2RhdGEgPiAwKQogCXdpZHRoID0gdXNlclByZWZlcnJlZFdpZHRoX2Rh
dGE7CkBAIC0xNDMsNyArMTQ1LDcgQEANCiAgICAgY2hhcltdIHRleHQoKSB7IHJldHVybiB0ZXh0
X2RhdGE7IH0KICAgICB2b2lkIHRleHQoY2hhcltdIGMpIHsKICAgICAgIHRleHRfZGF0YSA9IGM7
Ci0gICAgICBTZW5kTWVzc2FnZUEocGVlcixXTV9TRVRURVhULDAsY2FzdChMUEFSQU0pdG9TdHJp
bmd6KGMpKTsKKyAgICAgIFNlbmRNZXNzYWdlVyhwZWVyLFdNX1NFVFRFWFQsMCxjYXN0KExQQVJB
TSl0b1VURjE2eihjKSk7CiAgICAgfQogICB9CiAKQEAgLTE1MSw3ICsxNTMsNyBAQA0KICAgICB0
aGlzKENvbXBvbmVudCBwYXJlbnQsIGNoYXJbXSB0ZXh0LCBjaGFyW10gbmFtZSA9ICIiKSB7CiAg
ICAgICBQZWVyRm9yQWRkIHBhcmVudHAgPSBwYXJlbnQuZ2V0UGVlckZvckFkZCgpOwogICAgICAg
dGV4dF9kYXRhID0gdGV4dDsKLSAgICAgIHBlZXIgPSBDcmVhdGVXaW5kb3dBKCJCVVRUT04iLHRv
U3RyaW5neih0ZXh0KSwKKyAgICAgIHBlZXIgPSBDcmVhdGVXaW5kb3dXKCJCVVRUT04idyx0b1VU
RjE2eih0ZXh0KSwKIAkJCSAgIEJTX1BVU0hCVVRUT04gfCBXU19DSElMRCB8IFdTX1ZJU0lCTEUs
CiAJCQkgICAwLDAsMTAsMTAscGFyZW50cCwKIAkJCSAgIGNhc3QoSE1FTlUpMCxnQXBwLmhJbnN0
YW5jZSxudWxsKTsKQEAgLTE2Niw3ICsxNjgsNyBAQA0KICAgICB0aGlzKENvbXBvbmVudCBwYXJl
bnQsIGNoYXJbXSB0ZXh0LCBjaGFyW10gbmFtZSA9ICIiKSB7CiAgICAgICBQZWVyRm9yQWRkIHBh
cmVudHAgPSBwYXJlbnQuZ2V0UGVlckZvckFkZCgpOwogICAgICAgdGV4dF9kYXRhID0gdGV4dDsK
LSAgICAgIHBlZXIgPSBDcmVhdGVXaW5kb3dBKCJCVVRUT04iLHRvU3RyaW5neih0ZXh0KSwKKyAg
ICAgIHBlZXIgPSBDcmVhdGVXaW5kb3dXKCJCVVRUT04idyx0b1VURjE2eih0ZXh0KSwKIAkJCSAg
IEJTX0FVVE9DSEVDS0JPWCB8IFdTX0NISUxEIHwgV1NfVklTSUJMRSwKIAkJCSAgIDAsMCwxMCwx
MCxwYXJlbnRwLAogCQkJICAgY2FzdChITUVOVSkwLGdBcHAuaEluc3RhbmNlLG51bGwpOwpAQCAt
MTgyLDcgKzE4NCw3IEBADQogICAgIHRoaXMoQ29tcG9uZW50IHBhcmVudCwgY2hhcltdIGludGV4
dCwgY2hhcltdIG5hbWUgPSAiIikgewogICAgICAgUGVlckZvckFkZCBwYXJlbnRwID0gcGFyZW50
LmdldFBlZXJGb3JBZGQoKTsKICAgICAgIHRleHRfZGF0YSA9IGludGV4dDsKLSAgICAgIHBlZXIg
PSBDcmVhdGVXaW5kb3dBKCJCVVRUT04iLHRvU3RyaW5neihpbnRleHQpLAorICAgICAgcGVlciA9
IENyZWF0ZVdpbmRvd1coIkJVVFRPTiJ3LHRvVVRGMTZ6KGludGV4dCksCiAJCQkgICBCU19SQURJ
T0JVVFRPTiB8IFdTX0NISUxEIHwgV1NfVklTSUJMRSwKIAkJCSAgIDAsMCwxMCwxMCxwYXJlbnRw
LAogCQkJICAgY2FzdChITUVOVSkwLGdBcHAuaEluc3RhbmNlLG51bGwpOwpAQCAtMTk4LDcgKzIw
MCw3IEBADQogICAgIHRoaXMoQ29tcG9uZW50IHBhcmVudCwgY2hhcltdIHRleHQsIGNoYXJbXSBu
YW1lID0gIiIpIHsKICAgICAgIFBlZXJGb3JBZGQgcGFyZW50cCA9IHBhcmVudC5nZXRQZWVyRm9y
QWRkKCk7CiAgICAgICB0ZXh0X2RhdGEgPSB0ZXh0OwotICAgICAgcGVlciA9IENyZWF0ZVdpbmRv
d0EoIkJVVFRPTiIsdG9TdHJpbmd6KHRleHQpLAorICAgICAgcGVlciA9IENyZWF0ZVdpbmRvd1co
IkJVVFRPTiJ3LHRvVVRGMTZ6KHRleHQpLAogCQkJICAgQlNfUFVTSExJS0UgfCBCU19BVVRPQ0hF
Q0tCT1ggfCBXU19DSElMRCB8IFdTX1ZJU0lCTEUsCiAJCQkgICAwLDAsMTAsMTAscGFyZW50cCwK
IAkJCSAgIGNhc3QoSE1FTlUpMCxnQXBwLmhJbnN0YW5jZSxudWxsKTsKSW5kZXg6IG1zd2luZG93
cy5kDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09DQotLS0gbXN3aW5kb3dzLmQJKHJldmlzaW9uIDUpDQorKysgbXN3aW5k
b3dzLmQJKHdvcmtpbmcgY29weSkNCkBAIC05LDYgKzksNyBAQA0KIGV4dGVybiAoV2luZG93cyk6
CiBleHBvcnQgQk9PTCBQb3N0TWVzc2FnZUEoSFdORCBoV25kLCBVSU5UIG1zZywgV1BBUkFNIHdQ
YXJhbSwgTFBBUkFNIGxQYXJhbSk7CiBleHBvcnQgQk9PTCBTZW5kTWVzc2FnZUEoSFdORCBoV25k
LCBVSU5UIG1zZywgV1BBUkFNIHdQYXJhbSwgTFBBUkFNIGxQYXJhbSk7CitleHBvcnQgQk9PTCBT
ZW5kTWVzc2FnZVcoSFdORCBoV25kLCBVSU5UIG1zZywgV1BBUkFNIHdQYXJhbSwgTFBBUkFNIGxQ
YXJhbSk7CiBleHBvcnQgVUlOVCBTZXRUaW1lcihIV05EIGhXbmQsIHVpbnQgaWQsdWludCB0aW1l
LCBUSU1FUlBST0MgcHJvYyk7CiBleHBvcnQgQk9PTCBLaWxsVGltZXIoSFdORCBoV25kLCB1aW50
IGlkKTsKIGV4cG9ydCBCT09MIElzV2luZG93VmlzaWJsZSAoSFdORCBoV25kKTsKQEAgLTI1LDYg
KzI2LDcgQEANCiBleHBvcnQgdXNob3J0IEdldEtleVN0YXRlKGludCBrZXkpOwogZXhwb3J0IEFU
T00gUmVnaXN0ZXJDbGFzc0V4QShXTkRDTEFTU0VYQSAqbHBXbmRDbGFzcyk7CiBleHBvcnQgQk9P
TCBHZXRUZXh0RXh0ZW50UG9pbnQzMkEoSERDIGRjLCBMUENTVFIgc3RyLCBpbnQgbGVuLCBTSVpF
KiBzKTsKK2V4cG9ydCBCT09MIEdldFRleHRFeHRlbnRQb2ludDMyVyhIREMgZGMsIExQV1NUUiBz
dHIsIGludCBsZW4sIFNJWkUqIHMpOwogZXhwb3J0IEJPT0wgSXNEaWFsb2dNZXNzYWdlQShIV05E
IGhXbmQsIFBNU0cgbXNnKTsKIGV4cG9ydCBpbnQgTG9hZFN0cmluZ0EoSElOU1RBTkNFIGluc3Qs
IExQU1RSIGlkLCBMUFRTVFIgYnVmLCBpbnQgc2l6KTsKIC8qCkBAIC0zOTUsMyArMzk3LDM0IEBA
DQogY29uc3QgdWludCBTQlNfU0laRUJPWFRPUExFRlRBTElHTiAgICAgPTB4MDAwMjsKIGNvbnN0
IHVpbnQgU0JTX1NJWkVCT1hCT1RUT01SSUdIVEFMSUdOID0weDAwMDQ7CiBjb25zdCB1aW50IFNC
U19TSVpFQk9YICAgICAgICAgICAgICAgICA9MHgwMDA4OworCitleHBvcnQgSFdORCBDcmVhdGVX
aW5kb3dFeFcoCisgICAgRFdPUkQgZHdFeFN0eWxlLAorICAgIExQV1NUUiBscENsYXNzTmFtZSwK
KyAgICBMUFdTVFIgbHBXaW5kb3dOYW1lLAorICAgIERXT1JEIGR3U3R5bGUsCisgICAgaW50IFgs
CisgICAgaW50IFksCisgICAgaW50IG5XaWR0aCwKKyAgICBpbnQgbkhlaWdodCwKKyAgICBIV05E
IGhXbmRQYXJlbnQgLAorICAgIEhNRU5VIGhNZW51LAorICAgIEhJTlNUQU5DRSBoSW5zdGFuY2Us
CisgICAgTFBWT0lEIGxwUGFyYW0pOworCisKK0hXTkQgQ3JlYXRlV2luZG93VygKKyAgICBMUFdT
VFIgbHBDbGFzc05hbWUsCisgICAgTFBXU1RSIGxwV2luZG93TmFtZSwKKyAgICBEV09SRCBkd1N0
eWxlLAorICAgIGludCBYLAorICAgIGludCBZLAorICAgIGludCBuV2lkdGgsCisgICAgaW50IG5I
ZWlnaHQsCisgICAgSFdORCBoV25kUGFyZW50ICwKKyAgICBITUVOVSBoTWVudSwKKyAgICBISU5T
VEFOQ0UgaEluc3RhbmNlLAorICAgIExQVk9JRCBscFBhcmFtKQoreworICAgIHJldHVybiBDcmVh
dGVXaW5kb3dFeFcoMCwgbHBDbGFzc05hbWUsIGxwV2luZG93TmFtZSwgZHdTdHlsZSwgWCwgWSwg
bldpZHRoLCBuSGVpZ2h0LCBoV25kUGFyZW50LCBoTWVudSwgaEluc3RhbmNlLCBscFBhcmFtKTsK
K30K

--Xananews.1.2.3--
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.

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