Re: A GUI library to begin with
Ach, and there is plugin for Windows Gtk+ runtime called WIMP which emulates Windows Native look, so situation with GtkD isn't so bad on Linux/FreeBSD and Windows. I guess the biggest problem is da Mac OSX platform. Monodevelop looks so f**cking ugly on Mac :D
Re: A GUI library to begin with
On Wednesday, 8 February 2012 at 03:55:41 UTC, Mr. Anonymous wrote: Hello, I want to start playing with D, and I'm looking at a GUI library to begin with. From what I see here: http://www.prowiki.org/wiki4d/wiki.cgi?GuiLibraries I have four choices: GtkD, DWT, DFL, DGui. Has anyone tried these? Any suggestions? What is the status of DWT? What's the difference between DFL and DGui? Why does GTK suck (I read that a couple of times). Thanks. GtkD seems to be the most mature and production ready for D. Although indeed, Gtk+ (and then GtkD) suffers from its lack of Native controls. The best solution would be QtD, but it looks like its abandoned. QtJambi isn't officially supported by Trolltech (Nokia, whatever :D) any more, so switching to Smoke would be the must. WxD works quite good, you need to keep in mind that it crashes with DMD64, GDC and LDC works fine. DWT could be nice if it gets 64bitz support and Mac/Cocoa port too. DFL seems to be Windows only? Tho I guess it isn't maintained anymore. Situation with D and GUI is kinda poor. I see hope in Andrej researches about wxPHP and bringing it to D. I see hope in reviewing QtD project, it used to be flagship product next to DWT for D. DWT could be nice too if 64bt for Windows/Linux and Cocoa will be in. As for now, I would use GtkD ;-)
Re: opDispatch shadowing toString - feature or bug?
On Thu, 01 Sep 2011 13:59:29 +0200, Timon Gehr wrote:
> static assert(isInputRange!Test);
> static assert(isInputRange!Test2);
>
> toString is not shadowed, but the implementation of writeln assumes that
> your types are an InputRange (they provide, by the means of opDispatch,
> front(), empty() and popFront())
>
> The fact that writeln([]); prints a new line instead of "[]" is a bug
> that has already been taken care of in a pull request afaik.
>
> This specific problem can be solved by making your types not follow the
> InputRange interface, by putting an appropriate constraint on your
> opDispatch.
>
>
> import std.stdio;
>
> struct Test
> {
> string opDispatch( string key )() if(key!="popFront") {
> return "I am dispatching in struct!";
> }
>
> string toString()
> {
> return "I am Test struct!";
> }
> }
>
> class Test2
> {
> string opDispatch( string key )() if(key!="popFront") {
> return "I am dispatching in class!";
> }
>
> string toString()
> {
> return "I am Test class!";
> }
> }
>
> void main()
> {
> Test test = Test();
> writeln ( test.s ); // I am dispatching in struct! writeln
( test.s()
> ); // I am dispatching in struct! writeln ( test ); //I am Test
struct!
>
> Test2 test2 = new Test2();
> writeln ( test2.s ); // I am dispatching in class! writeln
( test2.s()
> ); // I am dispatching in class! writeln ( test2 ); // I am Test
class!
> }
Yes, this fix the problem.
Hmm, after all its a bit loose of a keyword, becouse I can't use anymore
test.popFront. For example if class acts as a storage device
class Storage
{
string[ string ] vars;
string opDispatch( string key )() if ( key != "popFront" )
{
if ( key in vars ) return vars[ key ];
else return "";
}
string toString() { // implement me
}
}
auto storage = new Storage;
storage.vars["test"] = "I'm a test!";
storage.vars["popFront"] = "I'm a poping around! :D";
writeln( storage.test ); // I'm a test!
writeln( storage.popFront ); // error
Ofcours, in opDispatch I can use empty or front instead of popFront but
it is still loose of one keyword.
Looks like it's a loose I have to take :-)
Thank you very much for reply!
Best regards,
Damian Ziemba
Re: opDispatch shadowing toString - feature or bug?
On Thu, 01 Sep 2011 07:56:49 +, Christophe wrote:
> Try to create the method:
>
> const void toString(void delegate(const(char)[]) sink, string
> formatString) {
> sink(toString());
> }
Adding it as it is results in compiler error:
./quick.d(30): Error: function quick.Test2.toString () is not c
allable using argument types () const
./quick.d(30): Error: expected 2 function arguments, not 0
./quick.d(30): Error: cannot implicitly convert expression
(this.toString()) of type void to const(char)[]
Removing const from begging allows it to compile. But it doesn't change
anything. Still "nothing" appears ;-)
opDispatch shadowing toString - feature or bug?
Greetings.
I've been playing around with opDispatch and toString methods and I found
strange behavior.
Example:
import std.stdio;
struct Test
{
string opDispatch( string key )()
{
return "I am dispatching in struct!";
}
string toString()
{
return "I am Test struct!";
}
}
class Test2
{
string opDispatch( string key )()
{
return "I am dispatching in class!";
}
string toString()
{
return "I am Test class!";
}
}
void main()
{
Test test = Test();
writeln ( test.s ); // I am dispatching in struct!
writeln ( test.s() ); // I am dispatching in struct!
writeln ( test ); // NOTHING :( But should return "I am
Test struct!"
Test2 test2 = new Test2();
writeln ( test2.s ); // I am dispatching in class!
writeln ( test2.s() ); // I am dispatching in class!
writeln ( test2 ); // NOTHING :( But should return "I am
Test class!"
}
Is it a feature or a bug?
Best regards,
Damian Ziemba
