www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GUI library for D

reply Matthias Pleh <jens konrad.net> writes:
was: [GSoC] Container proposals by Ishan and Christian

To preventing losing this thread, I have created a new one ...
Additional, I've added a license column on the GuiLibraries-table on the 
wiki.

So, let me summarize my thoughts, why I think a good Gui library is 
important for the D community.
I'm working for an enginge builder company. Our product is mainly 
mechanical, but also has a software part, which is created and 
maintained by a 16 (and growing) man team. Our softwareproduct is mainly 
server-side and timecritical, written in C++/MFC and very old. We've 
decided to create it new from scratch. As a member of the design team of 
this new project I've tried to inturoduce D for this. But it was 
impossible to assure the others. The main counter-argument was the lack 
of a good D-Gui library, though the main part is serverside, but the 
client-side GUI have to be written in the same language.

This were the requirments for the GUI library:
- Corss-platform (Win/linux)
- not just a port, but adjusted to the language
- mostly written in this language, so you can easy debug the lib,
   this means no wrapper library, just system libraries
   (Though gtk+ on linux would hold as a system library so GtkD for 
linux would be OK, but not on Windows!
- obviously suitable license for a commercial product

Unfortunately All known GUI-libraries for D fails on this requirments
So the choice has fallen to C++/Qt

I would like to fill this gap and create a really good D GUI library

Any thoughts, comments ... ?


°Matthias
Apr 04 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 04.04.2011 23:27, schrieb Matthias Pleh:

 was: [GSoC] Container proposals by Ishan and Christian
 
 To preventing losing this thread, I have created a new one ...
 Additional, I've added a license column on the GuiLibraries-table on the
 wiki.
 
 So, let me summarize my thoughts, why I think a good Gui library is
 important for the D community.
 I'm working for an enginge builder company. Our product is mainly
 mechanical, but also has a software part, which is created and
 maintained by a 16 (and growing) man team. Our softwareproduct is mainly
 server-side and timecritical, written in C++/MFC and very old. We've
 decided to create it new from scratch. As a member of the design team of
 this new project I've tried to inturoduce D for this. But it was
 impossible to assure the others. The main counter-argument was the lack
 of a good D-Gui library, though the main part is serverside, but the
 client-side GUI have to be written in the same language.
 
 This were the requirments for the GUI library:
 - Corss-platform (Win/linux)


Don't forget Mac OSX.
Also note that on Linux there are two widely used toolkits, GTK and Qt,
and that QT is better in emulating GTK than the other way round (you can
let GTK use the current QT theme or something, but it'll still use the
GTK filepicker etc. QT's GTK emulation is better and uses the real GTK
filepicker).


 - not just a port, but adjusted to the language
 - mostly written in this language, so you can easy debug the lib,
   this means no wrapper library, just system libraries
   (Though gtk+ on linux would hold as a system library so GtkD for linux
 would be OK, but not on Windows!
 - obviously suitable license for a commercial product
 
 Unfortunately All known GUI-libraries for D fails on this requirments
 So the choice has fallen to C++/Qt
 
 I would like to fill this gap and create a really good D GUI library
 
 Any thoughts, comments ... ?
 
 
 °Matthias


I don't know if wee need yet another GUI library.
Are you sure Qt and DWT aren't good enough?

Cheers,
- Daniel
Apr 04 2011
next sibling parent reply Matthias Pleh <jens konrad.net> writes:
Am 04.04.2011 23:34, schrieb Daniel Gibson:

 Am 04.04.2011 23:27, schrieb Matthias Pleh:

 was: [GSoC] Container proposals by Ishan and Christian




[snip]

 This were the requirments for the GUI library:
 - Corss-platform (Win/linux)


 Don't forget Mac OSX.


I just listed the requirments in our company, but you're rigth. We must 
support at least the three main platforms Win/linux/OSX


 Also note that on Linux there are two widely used toolkits, GTK and Qt,
 and that QT is better in emulating GTK than the other way round (you can
 let GTK use the current QT theme or something, but it'll still use the
 GTK filepicker etc. QT's GTK emulation is better and uses the real GTK
 filepicker).


that's true



[snip]

 I don't know if wee need yet another GUI library.


I have not said, that it must be create a completly new library.
We just have to find out, what are the requirments for the D community, 
and how can we achieve that.
Whe have mainly 4 options:
- support an existing project and help to meet our requirments
- fork an existing project and advance it to our requirments
- port a library from another language and advance it, to meet better
   the D coding style
- create a new library (which also can be based on a older abandoned
   project)


 Are you sure Qt and DWT aren't good enough?


As I mentioned in my post, I couldn't assure the others. Not every 
decision-maker base his decisions on pure technical arguments, sometimes 
it's just his gut feeling or the cleaning lady's advice, who knows :)

°Matthias



 Apr 04 2011



 next sibling parent reply Daniel Gibson <metalcaedes gmail.com>  writes:


Am 04.04.2011 23:51, schrieb Matthias Pleh:

 Am 04.04.2011 23:34, schrieb Daniel Gibson:

 Am 04.04.2011 23:27, schrieb Matthias Pleh:

 was: [GSoC] Container proposals by Ishan and Christian




 [snip]

 This were the requirments for the GUI library:
 - Corss-platform (Win/linux)


 Don't forget Mac OSX.


 I just listed the requirments in our company, but you're rigth. We must
 support at least the three main platforms Win/linux/OSX
 

 Also note that on Linux there are two widely used toolkits, GTK and Qt,
 and that QT is better in emulating GTK than the other way round (you can
 let GTK use the current QT theme or something, but it'll still use the
 GTK filepicker etc. QT's GTK emulation is better and uses the real GTK
 filepicker).


 that's true
 


 [snip]

 I don't know if wee need yet another GUI library.


 I have not said, that it must be create a completly new library.
 We just have to find out, what are the requirments for the D community,
 and how can we achieve that.
 Whe have mainly 4 options:
 - support an existing project and help to meet our requirments
 - fork an existing project and advance it to our requirments
 - port a library from another language and advance it, to meet better
   the D coding style
 - create a new library (which also can be based on a older abandoned
   project)
 

 Are you sure Qt and DWT aren't good enough?


 As I mentioned in my post, I couldn't assure the others. Not every
 decision-maker base his decisions on pure technical arguments, sometimes
 it's just his gut feeling or the cleaning lady's advice, who knows :)
 
 °Matthias


Maybe your company could help the DWT or QtD guys?
Getting something stable out of that would most probably not take as
long as developing your own cross-platform GUI toolkit.
Furthermore many people are already familiar with SWT and Qt, so they
wouldn't have to learn another toolkit for D.

Cheers,
- Daniel



 Apr 04 2011



  parent reply Matthias Pleh <jens konrad.net>  writes:


Am 05.04.2011 00:14, schrieb Daniel Gibson:

 Maybe your company could help the DWT or QtD guys?
 Getting something stable out of that would most probably not take as
 long as developing your own cross-platform GUI toolkit.
 Furthermore many people are already familiar with SWT and Qt, so they
 wouldn't have to learn another toolkit for D.


You have missed the point. For our company the decision is made. We 
already use C++/Qt now.
But I really like the D programming language and I use it for all my 
private projects. So I think, we, as the D community, should create a 
modern D GUI library entirely written in D.



 Apr 04 2011



 next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com>  writes:


On 2011-04-04 15:41, Matthias Pleh wrote:

 Am 05.04.2011 00:14, schrieb Daniel Gibson:

 Maybe your company could help the DWT or QtD guys?
 Getting something stable out of that would most probably not take as
 long as developing your own cross-platform GUI toolkit.
 Furthermore many people are already familiar with SWT and Qt, so they
 wouldn't have to learn another toolkit for D.


 
 You have missed the point. For our company the decision is made. We
 already use C++/Qt now.
 But I really like the D programming language and I use it for all my
 private projects. So I think, we, as the D community, should create a
 modern D GUI library entirely written in D.


Feel free to do that if you want, but I think that most people around here 
would agree that your time would be better spent improving the existing GUI 
toolkit bindings - such as qtd or dwt. A _lot_ of time and effort goes into 
making a truly solid and complete GUI toolkit. Why duplicate all of that work? 
There's just too much else that needs to be done for D. And even if we _want_ 
duplicate that work with a GUI toolkit which is completely written in D, you'd 
need a large team to develop it properly. And given the general difficulties 
in getting contributors for the various major D projects, I rather doubt that 
you're going to manage that.

So, do whatever you want, but I really don't think that developing a new GUI 
toolkit for D is really the best use of your time. There's plenty of other 
stuff that needs doing which would be of greater value.

- Jonathan M Davis



 Apr 04 2011



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-04-05 01:16, Jonathan M Davis wrote:

 On 2011-04-04 15:41, Matthias Pleh wrote:

 Am 05.04.2011 00:14, schrieb Daniel Gibson:

 Maybe your company could help the DWT or QtD guys?
 Getting something stable out of that would most probably not take as
 long as developing your own cross-platform GUI toolkit.
 Furthermore many people are already familiar with SWT and Qt, so they
 wouldn't have to learn another toolkit for D.


 You have missed the point. For our company the decision is made. We
 already use C++/Qt now.
 But I really like the D programming language and I use it for all my
 private projects. So I think, we, as the D community, should create a
 modern D GUI library entirely written in D.


 Feel free to do that if you want, but I think that most people around here
 would agree that your time would be better spent improving the existing GUI
 toolkit bindings - such as qtd or dwt. A _lot_ of time and effort goes into
 making a truly solid and complete GUI toolkit. Why duplicate all of that work?
 There's just too much else that needs to be done for D. And even if we _want_
 duplicate that work with a GUI toolkit which is completely written in D, you'd
 need a large team to develop it properly. And given the general difficulties
 in getting contributors for the various major D projects, I rather doubt that
 you're going to manage that.

 So, do whatever you want, but I really don't think that developing a new GUI
 toolkit for D is really the best use of your time. There's plenty of other
 stuff that needs doing which would be of greater value.

 - Jonathan M Davis


I completely agree. Qt has been around since 1992 and SWT since the 
1990s, starting as a toolkit for smalltalk. They both have come very far 
in their development.

-- 
/Jacob Carlborg



 Apr 05 2011



  parent  Bruno Medeiros <brunodomedeiros+spam com.gmail>  writes:


On 05/04/2011 10:04, Jacob Carlborg wrote:

 On 2011-04-05 01:16, Jonathan M Davis wrote:

 On 2011-04-04 15:41, Matthias Pleh wrote:

 Am 05.04.2011 00:14, schrieb Daniel Gibson:

 Maybe your company could help the DWT or QtD guys?
 Getting something stable out of that would most probably not take as
 long as developing your own cross-platform GUI toolkit.
 Furthermore many people are already familiar with SWT and Qt, so they
 wouldn't have to learn another toolkit for D.


 You have missed the point. For our company the decision is made. We
 already use C++/Qt now.
 But I really like the D programming language and I use it for all my
 private projects. So I think, we, as the D community, should create a
 modern D GUI library entirely written in D.


 Feel free to do that if you want, but I think that most people around
 here
 would agree that your time would be better spent improving the
 existing GUI
 toolkit bindings - such as qtd or dwt. A _lot_ of time and effort goes
 into
 making a truly solid and complete GUI toolkit. Why duplicate all of
 that work?
 There's just too much else that needs to be done for D. And even if we
 _want_
 duplicate that work with a GUI toolkit which is completely written in
 D, you'd
 need a large team to develop it properly. And given the general
 difficulties
 in getting contributors for the various major D projects, I rather
 doubt that
 you're going to manage that.

 So, do whatever you want, but I really don't think that developing a
 new GUI
 toolkit for D is really the best use of your time. There's plenty of
 other
 stuff that needs doing which would be of greater value.

 - Jonathan M Davis


 I completely agree. Qt has been around since 1992 and SWT since the
 1990s, starting as a toolkit for smalltalk. They both have come very far
 in their development.


I completely agree too.
Even if DWT's Javaness is eventually completely unbearable for someone, 
it would still be much better to change it (even if as a 
fork/new-project and not part of the main project) than to build 
something entirely new from scratch.


-- 
Bruno Medeiros - Software Engineer



 Apr 07 2011



prev sibling  parent  "nedbrek" <nedbrek yahoo.com>  writes:


Hello all,

"Matthias Pleh" <jens konrad.net> wrote in message 
news:indhmm$3q4$1 digitalmars.com...

 Am 05.04.2011 00:14, schrieb Daniel Gibson:

 Maybe your company could help the DWT or QtD guys?
 Getting something stable out of that would most probably not take as
 long as developing your own cross-platform GUI toolkit.
 Furthermore many people are already familiar with SWT and Qt, so they
 wouldn't have to learn another toolkit for D.


 You have missed the point. For our company the decision is made. We 
 already use C++/Qt now.
 But I really like the D programming language and I use it for all my 
 private projects. So I think, we, as the D community, should create a 
 modern D GUI library entirely written in D.


Are you familiar with Tcl/Tk?  I am working on D bindings for them.  It is a 
lot less effort than reimplementing a whole GUI system!

Ned



 Apr 04 2011



prev sibling  parent reply Alvaro <alvaroDotSegura gmail.com>  writes:


El 04/04/2011 23:51, Matthias Pleh escribió:

 Am 04.04.2011 23:34, schrieb Daniel Gibson:

 Am 04.04.2011 23:27, schrieb Matthias Pleh:

 was: [GSoC] Container proposals by Ishan and Christian




 [snip]

 This were the requirments for the GUI library:
 - Corss-platform (Win/linux)


 Don't forget Mac OSX.


 I just listed the requirments in our company, but you're rigth. We must
 support at least the three main platforms Win/linux/OSX


 Also note that on Linux there are two widely used toolkits, GTK and Qt,
 and that QT is better in emulating GTK than the other way round (you can
 let GTK use the current QT theme or something, but it'll still use the
 GTK filepicker etc. QT's GTK emulation is better and uses the real GTK
 filepicker).


 that's true



 [snip]

 I don't know if wee need yet another GUI library.


 I have not said, that it must be create a completly new library.
 We just have to find out, what are the requirments for the D community,
 and how can we achieve that.
 Whe have mainly 4 options:
 - support an existing project and help to meet our requirments
 - fork an existing project and advance it to our requirments
 - port a library from another language and advance it, to meet better
 the D coding style
 - create a new library (which also can be based on a older abandoned
 project)


 Are you sure Qt and DWT aren't good enough?


 As I mentioned in my post, I couldn't assure the others. Not every
 decision-maker base his decisions on pure technical arguments, sometimes
 it's just his gut feeling or the cleaning lady's advice, who knows :)

 °Matthias


Why do you say "it must be a completely new library"? Why don't the 
existing ones fit?

I last week tried gtkD, both on Linux and Windows. Quite nice, only I 
don't really like how it looks on Windows, that it can't use the native 
controls. And then there is QtD and wxD (from wxWidgets) both using 
native controls.

Anyway I think I know what you mean by "the D coding style". All those 
are direct ports/bindings that retain their original style and don't 
really take advantage of D's facilities.

For instance, in gtkD (QtD probably too, haven't looked at it), classes 
have classic functions for accessing and modifying "properties", like 
window.setTitle("Find"); w=window.getWidth(). But D provides real 
 properties. That could be improved to window.title = "Find"; 
w=window.width; Etc, etc.

The use of properties, delegates for event handlers, D's Unicode 
strings, etc. could certainly be improved in libs like those. But anyway 
they have done a great job in providing D with working GUI APIs.



 Apr 04 2011



  parent reply Matthias Pleh <jens konrad.net>  writes:


Am 05.04.2011 00:35, schrieb Alvaro:

 El 04/04/2011 23:51, Matthias Pleh escribió:

 Am 04.04.2011 23:34, schrieb Daniel Gibson:

 Am 04.04.2011 23:27, schrieb Matthias Pleh:

 was: [GSoC] Container proposals by Ishan and Christian




 [snip]

 This were the requirments for the GUI library:
 - Corss-platform (Win/linux)


 Don't forget Mac OSX.


 I just listed the requirments in our company, but you're rigth. We must
 support at least the three main platforms Win/linux/OSX


 Also note that on Linux there are two widely used toolkits, GTK and Qt,
 and that QT is better in emulating GTK than the other way round (you can
 let GTK use the current QT theme or something, but it'll still use the
 GTK filepicker etc. QT's GTK emulation is better and uses the real GTK
 filepicker).


 that's true



 [snip]

 I don't know if wee need yet another GUI library.


 I have not said, that it must be create a completly new library.
 We just have to find out, what are the requirments for the D community,
 and how can we achieve that.
 Whe have mainly 4 options:
 - support an existing project and help to meet our requirments
 - fork an existing project and advance it to our requirments
 - port a library from another language and advance it, to meet better
 the D coding style
 - create a new library (which also can be based on a older abandoned
 project)


 Are you sure Qt and DWT aren't good enough?


 As I mentioned in my post, I couldn't assure the others. Not every
 decision-maker base his decisions on pure technical arguments, sometimes
 it's just his gut feeling or the cleaning lady's advice, who knows :)

 °Matthias


 Why do you say "it must be a completely new library"? Why don't the
 existing ones fit?


No, see above, supporting an existing library would also fit.


 I last week tried gtkD, both on Linux and Windows. Quite nice, only I
 don't really like how it looks on Windows, that it can't use the native
 controls. And then there is QtD and wxD (from wxWidgets) both using
 native controls.

 Anyway I think I know what you mean by "the D coding style". All those
 are direct ports/bindings that retain their original style and don't
 really take advantage of D's facilities.


Yes exactly. The argument by others was, that a community which is not 
able to create their own library, coded in their own style, will not 
survive.


 For instance, in gtkD (QtD probably too, haven't looked at it), classes
 have classic functions for accessing and modifying "properties", like
 window.setTitle("Find"); w=window.getWidth(). But D provides real
  properties. That could be improved to window.title = "Find";
 w=window.width; Etc, etc.

 The use of properties, delegates for event handlers, D's Unicode
 strings, etc. could certainly be improved in libs like those. But anyway
 they have done a great job in providing D with working GUI APIs.


Don't get me wrong. GtkD perfectly meets my personal taste and I would 
have used this library for our project. But others are more cautios and 
have really strong requirments for such a projects (Note, this is one 
big project with much more than 500.000 LOC), so we _already_ have 
choosen C++/Qt !!

I think other companies will have similar decision. So, I think, to help 
D to get more accepted in the buisiness world, one requirement would be 
a good GUI library.

°Matthias



 Apr 04 2011



  parent  Gour-Gadadhara Dasa <gour atmarama.net>  writes:


On Tue, 05 Apr 2011 01:06:26 +0200
Matthias Pleh <jens konrad.net> wrote:


 I think other companies will have similar decision. So, I think, to
 help D to get more accepted in the buisiness world, one requirement
 would be a good GUI library.


Coming from the Haskell I can say that e.g. gtk2hs bindings provide
quite a nice higher-level API (using Haskell style) on top of
low-level C API provided by GTK+.

Same thing can be done for e.g. QtD instead of spending time creating
something from the scratch.


Sincerely,
Gour

--=20
=E2=80=9CIn the material world, conceptions of good and bad are
all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu)

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810



 Apr 05 2011



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:inddni$kmi$3 digitalmars.com...

 I don't know if wee need yet another GUI library.
 Are you sure Qt and DWT aren't good enough?


AIUI:

DWT doesn't support D2 (neither does wxD).

QtD requires a patched DMD, MinGW (which is fucking god-awful), and cmake (I 
have to let some variant of "make" touch my computer? Why can't we just let 
make die?). And it requires running your code through a preprocessor.

And none of those have actual API documentation, they just refer to the 
C/C++ docs. I use D because I never want to look at another line of C++ as 
long as I live.

Everything else is either non-native or non-cross-platform.

The state of GUIs in D right now is pretty awful, unfortunately. My plate's 
already overpacked (think: teenager at a one-trip buffet), but maybe I'll 
see if I can squeeze in enough extra time (hah! there's a concept I've 
completely lost all memory of) to try to help out on something. After all, I 
*really* want to get around to making my own web browser (based off either 
Mozilla or Chromium) - I'm getting really fed up with the current state of 
available web browsers. Well, and the web as a whole (god I fucking hate the 
web), but one step at a time, I guess).



 Apr 04 2011



 next sibling parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


Nick Sabalausky wrote:

 QtD requires a patched DMD [...] And it requires running your code through a


preprocessor.

I think your info is a little out of date (much like the QtD
documentation...)

But when I tried it last month, stock DMD worked with it, and
the build process was fairly straight forward once I had all
the stuff setup.

It worked quite well on Linux, but Windows was a little different...

...It came *very* close to working for me, but would randomly
crash in painter code on Windows (access violation). I suspect
there was something to blame with a painter class being prematurely
destroyed, but when I looked at the code, I couldn't nail down
the cause, and ultimately gave up in favor of my D/C++ hybrid
approach.



 Apr 04 2011



 next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


On 4/5/11, Adam D. Ruppe <destructionator gmail.com> wrote:

 I think your info is a little out of date (much like the QtD
 documentation...)

 But when I tried it last month, stock DMD worked with it, and
 the build process was fairly straight forward once I had all
 the stuff setup.


No, it still requires the patch for some code. I've had a bug report
where I was told to patch DMD.



 Apr 04 2011



 next sibling parent reply "Nick Sabalausky" <a a.a>  writes:


"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.3179.1301970476.4748.digitalmars-d puremagic.com...

 On 4/5/11, Adam D. Ruppe <destructionator gmail.com> wrote:

 I think your info is a little out of date (much like the QtD
 documentation...)

 But when I tried it last month, stock DMD worked with it, and
 the build process was fairly straight forward once I had all
 the stuff setup.


 No, it still requires the patch for some code. I've had a bug report
 where I was told to patch DMD.


Do we know what DMD tickets are needed to fix to make the patching obsolete?



 Apr 04 2011



 next sibling parent  Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


On 4/5/11, Nick Sabalausky <a a.a> wrote:

 "Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message
 news:mailman.3179.1301970476.4748.digitalmars-d puremagic.com...

 On 4/5/11, Adam D. Ruppe <destructionator gmail.com> wrote:

 I think your info is a little out of date (much like the QtD
 documentation...)

 But when I tried it last month, stock DMD worked with it, and
 the build process was fairly straight forward once I had all
 the stuff setup.


 No, it still requires the patch for some code. I've had a bug report
 where I was told to patch DMD.


 Do we know what DMD tickets are needed to fix to make the patching obsolete?


http://www.dsource.org/projects/qtd/wiki/DmdPatch
http://www.dsource.org/projects/qtd/attachment/wiki/DmdPatch/dmd.2.046.patch

Apparently this is used for some static introspection (I think so..).
It's just a few lines of code.



 Apr 04 2011



prev sibling  parent reply Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


You can follow these instructions to build, as long as you have CMake,
DMD2, and GCC installed and in path:

http://www.dsource.org/projects/qtd/wiki/BuildWindows

Also I have to warn you that QtD has shell scripts to build the
examples, but they're pretty much hardcoded for D1. Also many examples
can only be compiled with D1.

I've made some batch files for the examples, and changed examples to
compile with D2. Not all of them though. If you need them, I'll just
double-check that they still work and I'll send them over.



 Apr 04 2011



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.3181.1301971416.4748.digitalmars-d puremagic.com...

 You can follow these instructions to build, as long as you have CMake,
 DMD2, and GCC installed and in path:


GCC, really? Even on Windows? (GCC on Windows is such a nightmare.)


 http://www.dsource.org/projects/qtd/wiki/BuildWindows


Ok, so the steps in there *are* required then. I wasn't sure if that was to 
*use* QtD or just to re-compile some .lib or something.


 Also I have to warn you that QtD has shell scripts to build the
 examples, but they're pretty much hardcoded for D1. Also many examples
 can only be compiled with D1.

 I've made some batch files for the examples, and changed examples to
 compile with D2. Not all of them though. If you need them, I'll just
 double-check that they still work and I'll send them over. 





 Apr 04 2011



 next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


On 4/5/11, Nick Sabalausky <a a.a> wrote:

 GCC, really? Even on Windows? (GCC on Windows is such a nightmare.)


 http://www.dsource.org/projects/qtd/wiki/BuildWindows




Just download and run it and don't worry about it too much:
http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-get-inst/mingw-get-inst-20110316/mingw-get-inst-20110316.exe/download

As long as you can invoke gcc.exe, you're set. The problem-makers are
those cygwin dependent libs, but QtD works fine without any cygwin
shenanigans.

Oh btw, I just found a cool trick today to figure out in what
directory an app resides. E.g. if you invoke "gcc.exe" and you want to
know where it's installed. Add this batch file to your path:

 setlocal
 set P2=.;%PATH%
 for %%e in (%PATHEXT%) do  for %%i in (%~n1%%e) do  if NOT
"%%~$P2:i"=="" echo %%~$P2:i

Then just run `where myapp.exe`, and it shows you the full path.



 Apr 04 2011



  parent  "Nick Sabalausky" <a a.a>  writes:


"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.3183.1301973158.4748.digitalmars-d puremagic.com...

 Oh btw, I just found a cool trick today to figure out in what
 directory an app resides. E.g. if you invoke "gcc.exe" and you want to
 know where it's installed. Add this batch file to your path:

  setlocal
  set P2=.;%PATH%
  for %%e in (%PATHEXT%) do  for %%i in (%~n1%%e) do  if NOT
 "%%~$P2:i"=="" echo %%~$P2:i

 Then just run `where myapp.exe`, and it shows you the full path.


Heh, sweet. Batch trickery. That really takes me back. That seems a useful 
tool, too.



 Apr 04 2011



prev sibling next sibling parent  Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


Right, so you need this:
ftp://ftp.qt.nokia.com/qtsdk/qt-sdk-win-opensource-2010.04.exe

After installing to C:\Qt or wherever, just add these two to PATH,
make sure they're before any other mingw path:
C:\Qt\2010.04\mingw\bin
C:\Qt\2010.04\qt\bin

(replace paths as necessary)



 Apr 04 2011



prev sibling  parent reply Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


Wait, I'm a dumbass!

Actually QtD needs to have Qt's MinGW in PATH, not the regular MinGW.
Hold on a second, let me see what you need to do..



 Apr 04 2011



  parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail>  writes:


On 05/04/2011 04:13, Andrej Mitrovic wrote:

 Wait, I'm a dumbass!

 Actually QtD needs to have Qt's MinGW in PATH, not the regular MinGW.
 Hold on a second, let me see what you need to do..


Qt has its own MinGW? o_o'

-- 
Bruno Medeiros - Software Engineer



 Apr 07 2011



  parent  Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


On 4/7/11, Bruno Medeiros <brunodomedeiros+spam com.gmail> wrote:

 On 05/04/2011 04:13, Andrej Mitrovic wrote:

 Wait, I'm a dumbass!

 Actually QtD needs to have Qt's MinGW in PATH, not the regular MinGW.
 Hold on a second, let me see what you need to do..


 Qt has its own MinGW? o_o'


I'm not sure what's special about it, maybe they've just preconfigured
it to work better for Qt. I think compilation of QtD fails unless you
use the one that's distributed with Qt.



 Apr 07 2011



prev sibling  parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


Andrej Mitrovic wrote:

 No, it still requires the patch for some code. I've had a bug
 report where I was told to patch DMD.


:-(

Still, it's /so/ close to being usable out of the box. I think
if someone could find a week or two to devote to it, we could
get the GUI part pretty solid.



 Apr 04 2011



  parent  Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


On 4/5/11, Adam D. Ruppe <destructionator gmail.com> wrote:

 Andrej Mitrovic wrote:

 No, it still requires the patch for some code. I've had a bug
 report where I was told to patch DMD.


 :-(

 Still, it's /so/ close to being usable out of the box. I think
 if someone could find a week or two to devote to it, we could
 get the GUI part pretty solid.


Yeah, the few examples that do compile look and run great. It would be
nice to be able to understand how this wrapper works at all. There are
multiple directories with source files and you have to run some code
generator before compiling Qt. It seems very complicated, I wouldn't
even know where to begin to start contributing.



 Apr 04 2011



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:induia$vo2$1 digitalmars.com...

 Nick Sabalausky wrote:

 QtD requires a patched DMD [...] And it requires running your code 
 through a


 preprocessor.

 I think your info is a little out of date (much like the QtD
 documentation...)

 But when I tried it last month, stock DMD worked with it, and
 the build process was fairly straight forward once I had all
 the stuff setup.


Looking at the pages that are there for QtD, and the source browser, I'm 
honestly not sure how to even get started with it. Ie, to get from where I 
am right now (no Qt or QtD at all) to actually compiling any of the examples 
or any other program that uses QtD. Do you remember enough to point me in 
the right direction?


 It worked quite well on Linux, but Windows was a little different...

 ...It came *very* close to working for me, but would randomly
 crash in painter code on Windows (access violation). I suspect
 there was something to blame with a painter class being prematurely
 destroyed, but when I looked at the code, I couldn't nail down
 the cause, and ultimately gave up in favor of my D/C++ hybrid
 approach.





 Apr 04 2011



  parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


Nick Sabalausky wrote:

 Looking at the pages that are there for QtD, and the source
 browser, I'm honestly not sure how to even get started with it.


Somewhere, there was a binary distribution with the needed .libs..
I don't remember where, but I think I still have a copy on my
other laptop (not available right now though).

Note that the duic for Qt Designer files apparently is behind
some changes - it won't work right. Gotta write straight D yourself.

But, you install it however, the process on the site I think works
but it takes a little while.

Anyway, here's a hello world I just whipped up with some comments
to keep in mind - stuff that took me hours to figure out...

The compile line looks like this on Linux:
dmd hello.d -I/usr/local/include/d -L-L/usr/local/lib -L-lqtdgui -L-lqtdcore
-L-lcpp_core -L-lcpp_gui -L-lQtGui -L-lQtCore

Note it takes a few seconds to compile. Pretty slow for D.

It's similar on Windows, but since I don't have my win laptop
available right now I don't quite remember what it was exactly.

Anyway, the program:

// Qt's files are pulled in from the qt.gui or qt.core packages
// Seems to require a pretty long list of imports....
import qt.gui.QApplication;
import qt.gui.QMessageBox;
import qt.gui.QPushButton;
import qt.gui.QWidget;

int main(string[] args) {
    // main looks a lot like a C++ qt program, right down to
    // wanting scope classes so the destructors run in order

    scope app = new QApplication(args);

    scope mywindow = new MyWindow();
    mywindow.show();

    return app.exec();
}

class MyWindow : QWidget {
    this() {
         button = new QPushButton(this);
         setWindowTitle("Hello"); // methods are same as C++ but
                                  // thankfully they use D strings

         // signals and slots are connected by putting the signature
         // in quotes. No need for the SIGNAL or SLOT macro from C++
         // You leave the signal_ or slot_ off (see below)
         connect(button, "clicked", this, "sayHello");
    }

    // signals and slots use a naming convention instead of a label
    // like in C++. signals are declared: void signal_myName();
    // and here is a slot. When connecting, leave signal_ or slot_
    // off the string
    void slot_sayHello() {
         // the static call like in C++
         QMessageBox.information(null, "hello", "hello");
         this.close();
    }

    QPushButton button;

    // You must remember to mix this in for any class that uses
    // signals and slots to work, otherwise it will segfault at
    // runtime on the connect calls.

    // It's like the C++ Q_OBJECT macro, but while you'd normally
    // put the C++ macro at the top of the class, this mixin needs
    // to be at the bottom of the class or you'll hit forward
    // reference hell when compiling.

    mixin Q_OBJECT;
}



 Apr 04 2011



 next sibling parent reply "Nick Sabalausky" <a a.a>  writes:


"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:ine114$14ar$1 digitalmars.com...

 Nick Sabalausky wrote:

 Looking at the pages that are there for QtD, and the source
 browser, I'm honestly not sure how to even get started with it.


 Somewhere, there was a binary distribution with the needed .libs..
 I don't remember where, but I think I still have a copy on my
 other laptop (not available right now though).

 Note that the duic for Qt Designer files apparently is behind
 some changes - it won't work right. Gotta write straight D yourself.

 But, you install it however, the process on the site I think works
 but it takes a little while.

 Anyway, here's a hello world I just whipped up with some comments
 to keep in mind - stuff that took me hours to figure out...


Thanks.



 The compile line looks like this on Linux:
 dmd 
 hello.d -I/usr/local/include/d -L-L/usr/local/lib -L-lqtdgui -L-lqtdcore
 -L-lcpp_core -L-lcpp_gui -L-lQtGui -L-lQtCore


Hmm, I really wish DMD had a cmdline param to specify a library to be passed 
to the linker rather than needing to use "-L". Makes it impossible to write 
a cross-platform DMD command for anything that requires linking to a lib.

Should "pragma(lib, nameoflib);" work, or was that just a special thing in 
bu(il)d?



 Note it takes a few seconds to compile. Pretty slow for D.


Psshh. Compiling DDMD takes a minute or two. I can live with a few seconds 
:)



 It's similar on Windows, but since I don't have my win laptop
 available right now I don't quite remember what it was exactly.

 Anyway, the program:


[...snip...]

Thanks. That should help. It does seem that QtD could *really* use some 
D-ification, though. Like arrays of delegates instead of signals/slots. And 
properties instead of the get*/set* functions that trigger my flashbacks of 
Java.



 Apr 04 2011



 next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


On 4/5/11, Nick Sabalausky <a a.a> wrote:

 Hmm, I really wish DMD had a cmdline param to specify a library to be passed
 to the linker rather than needing to use "-L". Makes it impossible to write
 a cross-platform DMD command for anything that requires linking to a lib.


But you can pass .lib files directly to DMD, I don't understand why
people use -L.



 Apr 04 2011



 next sibling parent  Adam D. Ruppe <destructionator gmail.com>  writes:


Andrej Mitrovic wrote:

 I don't understand why people use -L.


I pass the .libs directly on Windows, but I don't think it
works on Linux... not sure actually though.

But pragma(lib) definitely works on both!



 Apr 04 2011



prev sibling  parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-04-05 05:42, Andrej Mitrovic wrote:

 On 4/5/11, Nick Sabalausky<a a.a>  wrote:

 Hmm, I really wish DMD had a cmdline param to specify a library to be passed
 to the linker rather than needing to use "-L". Makes it impossible to write
 a cross-platform DMD command for anything that requires linking to a lib.


 But you can pass .lib files directly to DMD, I don't understand why
 people use -L.


It's handy if you have a common directory with lib files.

-- 
/Jacob Carlborg



 Apr 05 2011



  parent reply Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


On 4/5/11, Jacob Carlborg <doob me.com> wrote:

 It's handy if you have a common directory with lib files.


Well I've always wanted to do that, but how eactly do you set a
library search directory with Optlink/DMD?



 Apr 05 2011



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-04-05 20:57, Andrej Mitrovic wrote:

 On 4/5/11, Jacob Carlborg<doob me.com>  wrote:

 It's handy if you have a common directory with lib files.


 Well I've always wanted to do that, but how eactly do you set a
 library search directory with Optlink/DMD?


Don't know about Optlink but on Posix systems it's: -L-L/path/to/libraires

-- 
/Jacob Carlborg



 Apr 05 2011



 next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


On 4/5/11, Jacob Carlborg <doob me.com> wrote:

 On 2011-04-05 20:57, Andrej Mitrovic wrote:

 On 4/5/11, Jacob Carlborg<doob me.com>  wrote:

 It's handy if you have a common directory with lib files.


 Well I've always wanted to do that, but how eactly do you set a
 library search directory with Optlink/DMD?


 Don't know about Optlink but on Posix systems it's: -L-L/path/to/libraires


Oh well that's an LD trick then. :)

I have figured out a way to do it with Optlink, but I have to use the
LIB environment variable. So in a batch file I could have:
set LIB=C:\PathToMyLib\;%LIB%
dmd test.d myLib.lib

This will work. I should update the dwiki entry and add this information there.



 Apr 05 2011



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-04-05 22:58, Andrej Mitrovic wrote:

 On 4/5/11, Jacob Carlborg<doob me.com>  wrote:

 On 2011-04-05 20:57, Andrej Mitrovic wrote:

 On 4/5/11, Jacob Carlborg<doob me.com>   wrote:

 It's handy if you have a common directory with lib files.


 Well I've always wanted to do that, but how eactly do you set a
 library search directory with Optlink/DMD?


 Don't know about Optlink but on Posix systems it's: -L-L/path/to/libraires


 Oh well that's an LD trick then. :)

 I have figured out a way to do it with Optlink, but I have to use the
 LIB environment variable. So in a batch file I could have:
 set LIB=C:\PathToMyLib\;%LIB%
 dmd test.d myLib.lib

 This will work. I should update the dwiki entry and add this information there.


Have a look at the lib section: 
http://www.digitalmars.com/ctg/optlink.html#operational

"The lib entry may be either a single file name or a pathname (with 
trailing "\") to a directory containing the libraries. "

-- 
/Jacob Carlborg



 Apr 05 2011



  parent reply David Wang <osx.david live.com>  writes:


Hi, all,

For the GUI library for D, Why don't consider the GTK+ 3.0?

It is a very very good GUI library and has been formally released
(now version maybe is 3.0.7), and it introduced a "GObject
Introspection" which can widely enlarge the programming languages'
bundling using (of course includes D Language).

"GObject Introspection" implements calling GObject easily and
fluently. It means that every Language just need to build
a 'GObject Introspection' bundle, then the Language can easily and
fluently call every API of GTK+ 3.0 through this bundle;
It is excited! you know, GTK+ is a very very good GUI level
library which was written in C Language.


Please consider to produce a 'GObject Introspection' bundle for D,
then through the bundle, D language can access every API in GTK+
3.0. By this way, we will get cost down and can achieve a very
good GUI library.

GTK+ can be used in Linux & OS X & Windows & FreeBST & Unix & ....

You can see that by this way, D can produce inestimably GUI Apps
for different platforms and do not need to change the code very
much.


Best regards.
David.



 Apr 06 2011



  parent reply "Nick Sabalausky" <a a.a>  writes:


"David Wang" <osx.david live.com> wrote in message 
news:inh3v8$u5q$1 digitalmars.com...

 Hi, all,

 For the GUI library for D, Why don't consider the GTK+ 3.0?



GTK+ apps are crap on Windows. And not real great on KDE either, AIUI. It 
only barely qualifies as "cross-platform".



 Apr 06 2011



 next sibling parent  Jacob Carlborg <doob me.com>  writes:


On 2011-04-06 09:35, Nick Sabalausky wrote:

 "David Wang"<osx.david live.com>  wrote in message
 news:inh3v8$u5q$1 digitalmars.com...

 Hi, all,

 For the GUI library for D, Why don't consider the GTK+ 3.0?



 GTK+ apps are crap on Windows. And not real great on KDE either, AIUI. It
 only barely qualifies as "cross-platform".


Same for Mac OS X. Then there's also the extra runtime dependencies.

-- 
/Jacob Carlborg



 Apr 06 2011



prev sibling  parent  David Wang <osx.david live.com>  writes:


=========
Nick Sabalausky (a a.a)

GTK+ apps are crap on Windows. And not real great on KDE either,
AIUI. It
only barely qualifies as "cross-platform".
=========

Well, if that so, I think if someone want to build a 'real good'
GUI library which be good on Windows, KDE or other places will
need to build from the very LOW level of the machine code or
something like this.

BTW, KDE (it was built based on Qt, and now Qt seems encounters
problems) is not so good, it ture not for argument.

Before, apps based on GTK+ 2.xx is really not so good on Windows
or other platforms (except Linux). But, please pay attention to
new changed features of GTK+ 3.0.

such as:
totally use Cairo to draw;
support X Input 2;
use CSS style themes;
multiple backend support of GDK (on X or Wayland or W32api, even
HTML5, or something else.);
added GtkApplication class;
....
....

And GTK+ 3 introduced a "GObject Introspection" which can widely
enlarge the programming languages' bundling using.

"GObject Introspection" implements calling GObject easily and
fluently. It means that every Language just need to build
a 'GObject Introspection' bundle, then the Language can easily and
fluently call every API of GTK+ 3.0 through this bundle;


What about the Qt now?
Do you think NOKIA or the company who has bought Qt from NOKIA
will still truely do theirs efforts on it?


Please consider this carefully and detailly. Not for arguments.


Best regards.
David.



 Apr 06 2011



prev sibling  parent reply Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


On 4/5/11, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:

 I should update the dwiki entry and add this information
 there.


Done: http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial/CompilingLinkingD#PassingsearchdirectoriesforlibraryfilestoOptlink

Which reminds me.. who is in charge of the layout on the left side of
the Wiki? I think it would be nice to have a "Tutorials" link or
section put up there. Right now you can get to it by going through the
HowTo first.



 Apr 05 2011



  parent reply Matthias Pleh <jens konrad.net>  writes:


Am 05.04.2011 23:08, schrieb Andrej Mitrovic:

 Which reminds me.. who is in charge of the layout on the left side of
 the Wiki? I think it would be nice to have a "Tutorials" link or
 section put up there. Right now you can get to it by going through the
 HowTo first.



Done!

P.S.: the main wiki-Template for wiki4d is on dTemplate
http://prowiki.org/wiki4d/wiki.cgi?dTemplate

But, be careful, you change the hole wiki!

°Matthias



 Apr 05 2011



  parent reply Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


On 4/5/11, Matthias Pleh <jens konrad.net> wrote:

 Done!

 P.S.: the main wiki-Template for wiki4d is on dTemplate
 http://prowiki.org/wiki4d/wiki.cgi?dTemplate

 But, be careful, you change the hole wiki!

 =B0Matthias


That's fantastic, thanks!



 Apr 05 2011



  parent  Matthias Pleh <jens konrad.net>  writes:


Am 06.04.2011 00:41, schrieb Andrej Mitrovic:

 the hole wiki!


I meant 'whole' of course

Should go to sleep ... ;)



 Apr 05 2011



prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


Nick Sabalausky wrote:

 Should "pragma(lib, nameoflib);" work, or was that just a special
 thing in bu(il)d?


Yes, that should work. I use it in my curl and mysql modules which
I use with straight DMD (as well as my own little build tool, which
simply downloads referenced modules from my http server and builds
the dmd command line automatically. http://arsdnet.net/dcode/build.d )


 That should help. It does seem that QtD could *really* use some
 D-ification, though.


Absolutely. That's one reason why I actually prefer my later
approach of doing my own approach - one version of my D windowing
system plan.

Here's some snippets from the program written in it (it's closed
source commercial for a client company, so can't post the whole
thing):

       // it uses runtime Qt Designer loading to avoid the long
       // process of porting all that code. Acts as a "release
       // valve" if you will from the limitations of my system.
       // the .ui file is created straight from the C++ tool
        auto window = new QtUicWidget(import("stb.ui"));
        window.show();

        // thanks to some opDispatch magic though, it feels almost
        // like a regular class, though you need to do dynamic casts
        auto accountBox = cast(TreeWidget) window.accountBox;

        // Arrays of delegates let you handle events. A few
        // different signatures for handlers are allowed.
        // (it's actually a struct emulating a delegate array)
        window.accountProvider.textChanged ~= (Variant[] args) {
             // snip
        }

         // unrelated by cool: my DataObject system works with sqlite too, along
with mysql and postgres (to a limited extent)!
        auto db = openDBAndCreateIfNotPresent("stb.db", import("stb.sql") [...]


            // qtConnect is another one of my escape valves
           // if I don't offer a D wrapper, you can still access
           // Qt events via strings, with extensions for D
           // delegates!
                qtConnect(dialog.getKeyButton, "clicked()", {
                        dwsapp.openBrowser("http://mysite.com");
                });


The thing above is implemented via a bunch of helper objects on
the C++ side, put into a QSignalMapper. It actually leaks a
little memory since there's no facility to delete the C++ object,
but it was too convenient to have.

You can also connect C++ signals to C++ slots directly, using the
same string syntax, just like in QtD. I found the delegates so
much more useful though that I always used them in this app.

        // a technique I first started using in Javascript that
        // I also use in D now too - a function creates a delegate
        // so it can be called in a loop, closing over the loop var
        void delegate() makeTextChanged(Item i, string id) {

        // Menu items are Actions, like in C++, but the delegate
        // is provided right there.
        auto newAccountAction = new Action("&New Account", {
                newAccount("", "New Account");
        });

        // property syntax for get/set
        newAccountAction.icon = new Image(cast(bytes) import("add.png"));

        // another escape valve - access C++ objects dynamically
        // It actually builds wrapper objects at runtime from the
        // .ui file so you can use the D extensions on it too
        window.actions["action_About"].triggered ~= {

        // Qt supports CSS, so I did that here too, extending it
        // for HSL colors (it was mentioned on the newsgroup and
        // I liked it!)
        window.setStyleSheet(fixupStylesheetHsl(`

        // the C++ event loop is put into a separate gui thread
        // all wrapped up in this call:
        int retv = dws.eventLoop();



Like I've said before about the dws, I really want to make it work
with a shitty javascript front end too - and made some progress
in an earlier version - but the Qt got more attention here since
I needed it for a work project and was under the clock. Hence,
the escape valves and relatively limited native functions.


But, like with all my D libraries, I do keep the copyright on
all of it, even when it's done directly for work, so I could
clean this up for release.

It uses some C++0x features in the DLL code, so it might be a
pain to compile, but I could distribute binaries; it's about 1 MB,
negligble next to Qt itself.

It works on both Windows and Linux.



 Apr 04 2011



  parent  Adam D. Ruppe <destructionator gmail.com>  writes:


I wrote:

 I found the delegates so
 much more useful though that I always used them in this app.


Correction: I did use some Qt -> Qt connections, but they were all
created in the Qt Designer instead of in the D code. Since the
.ui file is loaded up by Qt's own parser (with me inputting hooks
at the places needed to make them work with the D bridge classes),
it's functions all work, including signal/slot connections made
in the gui.



 Apr 04 2011



prev sibling  parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-04-05 05:23, Nick Sabalausky wrote:

 "Adam D. Ruppe"<destructionator gmail.com>  wrote in message
 news:ine114$14ar$1 digitalmars.com...

 Nick Sabalausky wrote:

 Looking at the pages that are there for QtD, and the source
 browser, I'm honestly not sure how to even get started with it.


 Somewhere, there was a binary distribution with the needed .libs..
 I don't remember where, but I think I still have a copy on my
 other laptop (not available right now though).

 Note that the duic for Qt Designer files apparently is behind
 some changes - it won't work right. Gotta write straight D yourself.

 But, you install it however, the process on the site I think works
 but it takes a little while.

 Anyway, here's a hello world I just whipped up with some comments
 to keep in mind - stuff that took me hours to figure out...


 Thanks.



 The compile line looks like this on Linux:
 dmd
 hello.d -I/usr/local/include/d -L-L/usr/local/lib -L-lqtdgui -L-lqtdcore
 -L-lcpp_core -L-lcpp_gui -L-lQtGui -L-lQtCore


 Hmm, I really wish DMD had a cmdline param to specify a library to be passed
 to the linker rather than needing to use "-L". Makes it impossible to write
 a cross-platform DMD command for anything that requires linking to a lib.

 Should "pragma(lib, nameoflib);" work, or was that just a special thing in
 bu(il)d?


pragma(lib) works but I don't think it's cross-platform. You have to 
specify the extension. DSSS/rebuild and bu(il)d supports pragma(link, 
"link") which lets you specify any options to the linker.


 Note it takes a few seconds to compile. Pretty slow for D.


 Psshh. Compiling DDMD takes a minute or two. I can live with a few seconds
 :)



 It's similar on Windows, but since I don't have my win laptop
 available right now I don't quite remember what it was exactly.

 Anyway, the program:


 [...snip...]

 Thanks. That should help. It does seem that QtD could *really* use some
 D-ification, though. Like arrays of delegates instead of signals/slots. And
 properties instead of the get*/set* functions that trigger my flashbacks of
 Java.



-- 
/Jacob Carlborg



 Apr 05 2011



  parent  Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


On 4/5/11, Jacob Carlborg <doob me.com> wrote:

 pragma(lib) works but I don't think it's cross-platform. You have to
 specify the extension.


Wouldn't this work?

version(Windows)
{
    libExt = ".lib";
}
version(Linux)
{
    libExt = ".a";
}

pragma(lib, "myLibrary" ~ libExt);



 Apr 05 2011



prev sibling  parent  Adam D. Ruppe <destructionator gmail.com>  writes:


BTW, before I gave up on it, I tried a lot of things and made
some progress in a few areas.

I actually came very close to getting a C++ object, compiled with
mingw's gcc, to link into D.

If you use coff2omf (included in the commercial Digital Mars
package), you can get the object files all in the same format.

Then, run implib (with the free DM compiler package IIRC) on the
mingw DLLs to make some .lib files.


Then link it all together... almost works. The next problem is
getting the correct C++ runtime objects in and initialized...
and that's where I gave up on it.


A similar, but much simpler approach, was to have g++ put out
a shared library. Then do implib on it to get a .lib to pass
to optlink. Boom, the program works as long as you bundle that
.dll g++ made in there too.

To communicate with your C++, use extern(C) functions. To have
C++ call back into D, pass it an extern(c) function pointer.

When I did my own Qt, I put the Qt event loop in its own thread
(created with std.concurrency.spawn), using D's message passing
to communicate with it and Qt signals/slots to keep the thread
straight on the C++ side.

Took a little setup code, but actually worked pretty well once
it was up and running. Tip though: don't actually cast things
to immutable when passing messages! The compiler's complaints
are there for a reason. Follow the rules, and it's fairly
simple and very reliable in my experience.


g++ -ogui.dll -shared mycplusplus.cpp
implib /s gui.dll gui.lib
dmd mydapp.d gui.lib



 Apr 04 2011



prev sibling next sibling parent  "Nick Sabalausky" <a a.a>  writes:


"Nick Sabalausky" <a a.a> wrote in message 
news:indrtb$reg$1 digitalmars.com...

 "Daniel Gibson" <metalcaedes gmail.com> wrote in message 
 news:inddni$kmi$3 digitalmars.com...

 I don't know if wee need yet another GUI library.
 Are you sure Qt and DWT aren't good enough?


 AIUI:

 DWT doesn't support D2 (neither does wxD).

 QtD requires a patched DMD, MinGW (which is fucking god-awful), and cmake 
 (I have to let some variant of "make" touch my computer? Why can't we just 
 let make die?). And it requires running your code through a preprocessor.

 And none of those have actual API documentation, they just refer to the 
 C/C++ docs. I use D because I never want to look at another line of C++ as 
 long as I live.

 Everything else is either non-native or non-cross-platform.

 The state of GUIs in D right now is pretty awful, unfortunately. My 
 plate's already overpacked (think: teenager at a one-trip buffet), but 
 maybe I'll see if I can squeeze in enough extra time (hah! there's a 
 concept I've completely lost all memory of) to try to help out on 
 something. After all, I *really* want to get around to making my own web 
 browser (based off either Mozilla or Chromium) - I'm getting really fed up 
 with the current state of available web browsers. Well, and the web as a 
 whole (god I fucking hate the web), but one step at a time, I guess).


Disclaimer: It's not my intent to belittle the hard work the DWT/QtD/wxD/etc 
developers put into the projects. I certainly appreciate the work and effort 
that's been put into them. We'd be a lot worse off without it.



 Apr 04 2011



prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


On 4/5/11, Nick Sabalausky <a a.a> wrote:

 After all, I
 *really* want to get around to making my own web browser (based off either
 Mozilla or Chromium) - I'm getting really fed up with the current state of
 available web browsers. Well, and the web as a whole (god I fucking hate the
 web), but one step at a time, I guess).


I'll be the first to install it.

Btw, there's a full web browser example in the QtD sources. But it has
to be ported to D2. And then you have to deal with any eventual bugs
along the way. :]



 Apr 04 2011



 next sibling parent  "Nick Sabalausky" <a a.a>  writes:


"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.3178.1301970383.4748.digitalmars-d puremagic.com...

 On 4/5/11, Nick Sabalausky <a a.a> wrote:

 After all, I
 *really* want to get around to making my own web browser (based off 
 either
 Mozilla or Chromium) - I'm getting really fed up with the current state 
 of
 available web browsers. Well, and the web as a whole (god I fucking hate 
 the
 web), but one step at a time, I guess).


 I'll be the first to install it.


Yay, so I'm not the only one after all :)

I think the hardest part of the project will be to resist the urge to stick 
in non-optional code to deliberately screw around with servers that try to 
push idiotic BS.

Somewhat related, but admittedly even more OT: Am I the only one that misses 
the Sherlock and Watson apps? Back when I was giving OSX a try, those were a 
big part of what attracted me to OSX in the first place. And then they 
promptly whithered and died in favor of inferior trends like AJAX and 
locking data directly into a proprietary viewer (now known as "a website"). 
(Whatever happened to data interchange and the separation of program and 
data? I feel like we're back in the stone age when Lotus 1-2-3 data stayed 
in Lotus, Excel data stayed in Excel, WordPerfect data stayed in 
WordPerfect, etc. If you want to browse Amazon's stock, you *must* use *the* 
viewer ("website") that Amazon provides. If you want to check a library's 
stock, you *must* use *the* [likely horribly broken] viewer ("website") that 
the library in question provides. If you want to watch a video, you *must* 
use *the* flash-based viewer that the site provides. Etc. WTF is this, 1989? 
Meh, more like "1984" apparently...)


 Btw, there's a full web browser example in the QtD sources. But it has
 to be ported to D2. And then you have to deal with any eventual bugs
 along the way. :]


Cool, I'll have to take a look. Any idea offhand what rendering engine it 
uses?



 Apr 04 2011



prev sibling next sibling parent reply "Nick Sabalausky" <a a.a>  writes:


"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.3178.1301970383.4748.digitalmars-d puremagic.com...

 On 4/5/11, Nick Sabalausky <a a.a> wrote:

 After all, I
 *really* want to get around to making my own web browser (based off 
 either
 Mozilla or Chromium) - I'm getting really fed up with the current state 
 of
 available web browsers. Well, and the web as a whole (god I fucking hate 
 the
 web), but one step at a time, I guess).


 I'll be the first to install it.

 Btw, there's a full web browser example in the QtD sources. But it has
 to be ported to D2. And then you have to deal with any eventual bugs
 along the way. :]


Ha! I may not need to do much after all: I was just looking through 
Wikipedia's giant list of browsers, found a few that looked potentially 
promising, tried them all and...well, was mostly disappointed. But the 
*last* one I had left to try I've been really impressed with so far:

Arora (Qt/WebKit)
http://code.google.com/p/arora/

I've only tried it breifly, but the UI is *actually nice*! Only modern 
browser out there with a UI that isn't absolutely horrid. I didn't even see 
*one* instance of invisible-text on my light-on-dark system, which is 
unbeleivavly rare among all software these days.

And it has a lot of essential stuff built in, like ad blocking, disableable 
JS, and a "ClickToFlash" which I haven't tried out yet. There's still a few 
things it seems like it might be missing, like equivalents to NoScript, 
BetterPrivacy and maybe DownloadHelper and DownThemAll, but most of those 
are less important to me, and even as it is right now it's a damn good 
start. Maybe I could add some of that remaining stuff, or heck, maybe even 
port the whole thing to D ;)



 Apr 05 2011



 next sibling parent  Kagamin <spam here.lot>  writes:


Nick Sabalausky Wrote:


 Ha! I may not need to do much after all: I was just looking through 
 Wikipedia's giant list of browsers, found a few that looked potentially 
 promising, tried them all and...well, was mostly disappointed. But the 
 *last* one I had left to try I've been really impressed with so far:
 
 Arora (Qt/WebKit)
 http://code.google.com/p/arora/


Tried it too. May be, it's a webkit bug, but sometimes it wraps text
incorrectly.



 Apr 05 2011



prev sibling next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-04-05 09:08, Nick Sabalausky wrote:

 "Andrej Mitrovic"<andrej.mitrovich gmail.com>  wrote in message
 news:mailman.3178.1301970383.4748.digitalmars-d puremagic.com...

 On 4/5/11, Nick Sabalausky<a a.a>  wrote:

 After all, I
 *really* want to get around to making my own web browser (based off
 either
 Mozilla or Chromium) - I'm getting really fed up with the current state
 of
 available web browsers. Well, and the web as a whole (god I fucking hate
 the
 web), but one step at a time, I guess).


 I'll be the first to install it.

 Btw, there's a full web browser example in the QtD sources. But it has
 to be ported to D2. And then you have to deal with any eventual bugs
 along the way. :]


 Ha! I may not need to do much after all: I was just looking through
 Wikipedia's giant list of browsers, found a few that looked potentially
 promising, tried them all and...well, was mostly disappointed. But the
 *last* one I had left to try I've been really impressed with so far:

 Arora (Qt/WebKit)
 http://code.google.com/p/arora/

 I've only tried it breifly, but the UI is *actually nice*! Only modern
 browser out there with a UI that isn't absolutely horrid. I didn't even see
 *one* instance of invisible-text on my light-on-dark system, which is
 unbeleivavly rare among all software these days.

 And it has a lot of essential stuff built in, like ad blocking, disableable
 JS, and a "ClickToFlash" which I haven't tried out yet. There's still a few
 things it seems like it might be missing, like equivalents to NoScript,
 BetterPrivacy and maybe DownloadHelper and DownThemAll, but most of those
 are less important to me, and even as it is right now it's a damn good
 start. Maybe I could add some of that remaining stuff, or heck, maybe even
 port the whole thing to D ;)


I think it looks quite similar to Firefox, at least the Mac OS X version.

-- 
/Jacob Carlborg



 Apr 05 2011



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Jacob Carlborg" <doob me.com> wrote in message 
news:inf285$30n8$1 digitalmars.com...

 On 2011-04-05 09:08, Nick Sabalausky wrote:

 "Andrej Mitrovic"<andrej.mitrovich gmail.com>  wrote in message
 news:mailman.3178.1301970383.4748.digitalmars-d puremagic.com...

 On 4/5/11, Nick Sabalausky<a a.a>  wrote:

 After all, I
 *really* want to get around to making my own web browser (based off
 either
 Mozilla or Chromium) - I'm getting really fed up with the current state
 of
 available web browsers. Well, and the web as a whole (god I fucking 
 hate
 the
 web), but one step at a time, I guess).


 I'll be the first to install it.

 Btw, there's a full web browser example in the QtD sources. But it has
 to be ported to D2. And then you have to deal with any eventual bugs
 along the way. :]


 Ha! I may not need to do much after all: I was just looking through
 Wikipedia's giant list of browsers, found a few that looked potentially
 promising, tried them all and...well, was mostly disappointed. But the
 *last* one I had left to try I've been really impressed with so far:

 Arora (Qt/WebKit)
 http://code.google.com/p/arora/

 I've only tried it breifly, but the UI is *actually nice*! Only modern
 browser out there with a UI that isn't absolutely horrid. I didn't even 
 see
 *one* instance of invisible-text on my light-on-dark system, which is
 unbeleivavly rare among all software these days.

 And it has a lot of essential stuff built in, like ad blocking, 
 disableable
 JS, and a "ClickToFlash" which I haven't tried out yet. There's still a 
 few
 things it seems like it might be missing, like equivalents to NoScript,
 BetterPrivacy and maybe DownloadHelper and DownThemAll, but most of those
 are less important to me, and even as it is right now it's a damn good
 start. Maybe I could add some of that remaining stuff, or heck, maybe 
 even
 port the whole thing to D ;)


 I think it looks quite similar to Firefox, at least the Mac OS X version.


On windows it looks *very* different from firefox (unless you count FF 1.x). 
Maybe FF actually bothers trying to integrate with the system on OSX, but on 
windows the out-of-the-box installs of FF2+ (and especially FF3+) are 
skinned, flashy atrocities. Not nearly as horrific as Chrome, but still ugly 
as hell. Also Arora doesn't have FF's AwfulBar.

Plus, Arora doesn't have the unified forward/back dropdowns. The unified 
forward/back dropdowns sounded good when I first heard about them, but ever 
since I tried them I've absolutely hated them.



 Apr 05 2011



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-04-05 21:18, Nick Sabalausky wrote:

 "Jacob Carlborg"<doob me.com>  wrote in message
 news:inf285$30n8$1 digitalmars.com...

 On 2011-04-05 09:08, Nick Sabalausky wrote:

 "Andrej Mitrovic"<andrej.mitrovich gmail.com>   wrote in message
 news:mailman.3178.1301970383.4748.digitalmars-d puremagic.com...

 On 4/5/11, Nick Sabalausky<a a.a>   wrote:

 After all, I
 *really* want to get around to making my own web browser (based off
 either
 Mozilla or Chromium) - I'm getting really fed up with the current state
 of
 available web browsers. Well, and the web as a whole (god I fucking
 hate
 the
 web), but one step at a time, I guess).


 I'll be the first to install it.

 Btw, there's a full web browser example in the QtD sources. But it has
 to be ported to D2. And then you have to deal with any eventual bugs
 along the way. :]


 Ha! I may not need to do much after all: I was just looking through
 Wikipedia's giant list of browsers, found a few that looked potentially
 promising, tried them all and...well, was mostly disappointed. But the
 *last* one I had left to try I've been really impressed with so far:

 Arora (Qt/WebKit)
 http://code.google.com/p/arora/

 I've only tried it breifly, but the UI is *actually nice*! Only modern
 browser out there with a UI that isn't absolutely horrid. I didn't even
 see
 *one* instance of invisible-text on my light-on-dark system, which is
 unbeleivavly rare among all software these days.

 And it has a lot of essential stuff built in, like ad blocking,
 disableable
 JS, and a "ClickToFlash" which I haven't tried out yet. There's still a
 few
 things it seems like it might be missing, like equivalents to NoScript,
 BetterPrivacy and maybe DownloadHelper and DownThemAll, but most of those
 are less important to me, and even as it is right now it's a damn good
 start. Maybe I could add some of that remaining stuff, or heck, maybe
 even
 port the whole thing to D ;)


 I think it looks quite similar to Firefox, at least the Mac OS X version.


 On windows it looks *very* different from firefox (unless you count FF 1.x).
 Maybe FF actually bothers trying to integrate with the system on OSX, but on
 windows the out-of-the-box installs of FF2+ (and especially FF3+) are
 skinned, flashy atrocities. Not nearly as horrific as Chrome, but still ugly
 as hell. Also Arora doesn't have FF's AwfulBar.


I'm referring to Firefox 4. What's the "AwfulBar" ?


 Plus, Arora doesn't have the unified forward/back dropdowns. The unified
 forward/back dropdowns sounded good when I first heard about them, but ever
 since I tried them I've absolutely hated them.



-- 
/Jacob Carlborg



 Apr 05 2011



  parent reply Daniel Gibson <metalcaedes gmail.com>  writes:


Am 05.04.2011 22:20, schrieb Jacob Carlborg:

 
 I'm referring to Firefox 4. What's the "AwfulBar" ?
 


Probably the "Awesomebar".. the feature in FF3+ that searches all
visisted URLs (and the page titles) for the word you type into the
URL-bar (and not just completes URLs like before).
http://blog.mozilla.com/blog/2008/04/21/a-little-something-awesome-about-firefox-3/

I personally like it.



 Apr 05 2011



 next sibling parent reply "Nick Sabalausky" <a a.a>  writes:


"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:infu1q$6bn$1 digitalmars.com...

 Am 05.04.2011 22:20, schrieb Jacob Carlborg:

 I'm referring to Firefox 4. What's the "AwfulBar" ?


 Probably the "Awesomebar".. the feature in FF3+ that searches all
 visisted URLs (and the page titles) for the word you type into the
 URL-bar (and not just completes URLs like before).
 http://blog.mozilla.com/blog/2008/04/21/a-little-something-awesome-about-firefox-3/


Yea, it's also really, really ugly. 



 Apr 05 2011



 next sibling parent  "Nick Sabalausky" <a a.a>  writes:


"Nick Sabalausky" <a a.a> wrote in message 
news:infvdk$1sb2$1 digitalmars.com...

 "Daniel Gibson" <metalcaedes gmail.com> wrote in message 
 news:infu1q$6bn$1 digitalmars.com...

 Am 05.04.2011 22:20, schrieb Jacob Carlborg:

 I'm referring to Firefox 4. What's the "AwfulBar" ?


 Probably the "Awesomebar".. the feature in FF3+ that searches all
 visisted URLs (and the page titles) for the word you type into the
 URL-bar (and not just completes URLs like before).
 http://blog.mozilla.com/blog/2008/04/21/a-little-something-awesome-about-firefox-3/


 Yea, it's also really, really ugly.


It turned out very much a love-it-or-hate-it feature (even more than most of 
what Mozilla does). A lot of people love the bar, a lot of people hate it.



 Apr 05 2011



prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Tue, 05 Apr 2011 16:49:00 -0400, Nick Sabalausky <a a.a> wrote:


 "Daniel Gibson" <metalcaedes gmail.com> wrote in message
 news:infu1q$6bn$1 digitalmars.com...

 Am 05.04.2011 22:20, schrieb Jacob Carlborg:

 I'm referring to Firefox 4. What's the "AwfulBar" ?


 Probably the "Awesomebar".. the feature in FF3+ that searches all
 visisted URLs (and the page titles) for the word you type into the
 URL-bar (and not just completes URLs like before).
 http://blog.mozilla.com/blog/2008/04/21/a-little-something-awesome-about-firefox-3/


 Yea, it's also really, really ugly.


You just like swimming upstream, don't you :)

I personally cannot live without that firefox feature, and when it stops  
working (which happens from time to time), I'm pissed.

-Steve



 Apr 05 2011



 next sibling parent reply "Nick Sabalausky" <a a.a>  writes:


"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.vthgdrtueav7ka steve-laptop...

 On Tue, 05 Apr 2011 16:49:00 -0400, Nick Sabalausky <a a.a> wrote:


 "Daniel Gibson" <metalcaedes gmail.com> wrote in message
 news:infu1q$6bn$1 digitalmars.com...

 Am 05.04.2011 22:20, schrieb Jacob Carlborg:

 I'm referring to Firefox 4. What's the "AwfulBar" ?


 Probably the "Awesomebar".. the feature in FF3+ that searches all
 visisted URLs (and the page titles) for the word you type into the
 URL-bar (and not just completes URLs like before).
 http://blog.mozilla.com/blog/2008/04/21/a-little-something-awesome-about-firefox-3/


 Yea, it's also really, really ugly.


 You just like swimming upstream, don't you :)

 I personally cannot live without that firefox feature, and when it stops 
 working (which happens from time to time), I'm pissed.


The thing is, it's idiotic to make changes like that non-optional. There's a 
*lot* of people who hate it.



 Apr 05 2011



  parent  "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Tue, 05 Apr 2011 17:15:21 -0400, Nick Sabalausky <a a.a> wrote:


 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.vthgdrtueav7ka steve-laptop...

 On Tue, 05 Apr 2011 16:49:00 -0400, Nick Sabalausky <a a.a> wrote:


 "Daniel Gibson" <metalcaedes gmail.com> wrote in message
 news:infu1q$6bn$1 digitalmars.com...

 Am 05.04.2011 22:20, schrieb Jacob Carlborg:

 I'm referring to Firefox 4. What's the "AwfulBar" ?


 Probably the "Awesomebar".. the feature in FF3+ that searches all
 visisted URLs (and the page titles) for the word you type into the
 URL-bar (and not just completes URLs like before).
 http://blog.mozilla.com/blog/2008/04/21/a-little-something-awesome-about-firefox-3/


 Yea, it's also really, really ugly.


 You just like swimming upstream, don't you :)

 I personally cannot live without that firefox feature, and when it stops
 working (which happens from time to time), I'm pissed.


 The thing is, it's idiotic to make changes like that non-optional.  
 There's a
 *lot* of people who hate it.


All the posts I've seen (searching for hate awesome bar) talk about how it  
does not find the links you type in, it only finds lots of other stuff you  
don't want.

I think they have fixed a lot of those problems.  It seems to 99% of the  
time find what I want.  It seems to find quite high on the list links  
where I type a portion of the address, which I believe is what FF2 used to  
do.

Opera's equivalent to the awesome bar, on the other hand, is next to  
useless.  So I can see how people would have hated it if it was like that  
originally.

For example, I sometimes want to post a link in my news post to a prior  
post.  In order to do this, I want to fire up webnews from  
digitalmars.com.  I figure typing in webnews would come up with the link,  
but opera doesn't.  If I type in digitalmars, then it's on the list, but  
not the first one.

In firefox, it's the first link when I type in webnews.

-Steve



 Apr 05 2011



prev sibling  parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail>  writes:


On 05/04/2011 21:54, Steven Schveighoffer wrote:

 On Tue, 05 Apr 2011 16:49:00 -0400, Nick Sabalausky <a a.a> wrote:


 "Daniel Gibson" <metalcaedes gmail.com> wrote in message
 news:infu1q$6bn$1 digitalmars.com...

 Am 05.04.2011 22:20, schrieb Jacob Carlborg:

 I'm referring to Firefox 4. What's the "AwfulBar" ?


 Probably the "Awesomebar".. the feature in FF3+ that searches all
 visisted URLs (and the page titles) for the word you type into the
 URL-bar (and not just completes URLs like before).
 http://blog.mozilla.com/blog/2008/04/21/a-little-something-awesome-about-firefox-3/


 Yea, it's also really, really ugly.


 You just like swimming upstream, don't you :)


It's just one thing after the other... :P Nick, if you're like this when 
you're still quite young, I can't imagine how you'll be when you get old 
to the age of 50 and 60...

Hum, maybe your grumpiness/anti-ness will get so incredibly high that it 
will actually overflow and revert to a low value. Then you'll be a 
happy, carefree spirit, sell you CRT that you've managed to keep working 
for so many decades (which by the time will be a relic worth a lot of 
money), buy one of those 4D infinite-resolution meta-spacial monitors 
that are the latest tech, start using all the latest and popular 
software and applications, including "MindBook" - kinda like Facebook, 
but a neuro-social network that connects everyone's mind (the mobile 
phone evolved into a neural communication device) and allows one to 
share one's thoughts directly to all friends (even private thoughts if 
you're not careful :P). It's the collective consciousness that is all 
the rage with the kids, and that all the old adults (ourselves that are 
young now) think is too 
fashionable/intrusive/dehumanizing/immoral/childish/not-childish/useless/wasteful/whatever-choose-your-own.

Or not. :P

PS: no offense intended. :)

-- 
Bruno Medeiros - Software Engineer



 Apr 07 2011



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Bruno Medeiros" <brunodomedeiros+spam com.gmail> wrote in message 
news:inl5cp$2gkf$1 digitalmars.com...

 On 05/04/2011 21:54, Steven Schveighoffer wrote:

 On Tue, 05 Apr 2011 16:49:00 -0400, Nick Sabalausky <a a.a> wrote:


 "Daniel Gibson" <metalcaedes gmail.com> wrote in message
 news:infu1q$6bn$1 digitalmars.com...

 Am 05.04.2011 22:20, schrieb Jacob Carlborg:

 I'm referring to Firefox 4. What's the "AwfulBar" ?


 Probably the "Awesomebar".. the feature in FF3+ that searches all
 visisted URLs (and the page titles) for the word you type into the
 URL-bar (and not just completes URLs like before).
 http://blog.mozilla.com/blog/2008/04/21/a-little-something-awesome-about-firefox-3/


 Yea, it's also really, really ugly.


 You just like swimming upstream, don't you :)


 It's just one thing after the other... :P Nick, if you're like this when 
 you're still quite young, I can't imagine how you'll be when you get old 
 to the age of 50 and 60...

 Hum, maybe your grumpiness/anti-ness will get so incredibly high that it 
 will actually overflow and revert to a low value. Then you'll be a happy, 
 carefree spirit, sell you CRT that you've managed to keep working for so 
 many decades (which by the time will be a relic worth a lot of money), buy 
 one of those 4D infinite-resolution meta-spacial monitors that are the 
 latest tech, start using all the latest and popular software and 
 applications, including "MindBook" - kinda like Facebook, but a 
 neuro-social network that connects everyone's mind (the mobile phone 
 evolved into a neural communication device) and allows one to share one's 
 thoughts directly to all friends (even private thoughts if you're not 
 careful :P).


I already have that "share private thoughts if you're not careful" thing. 
It's called talking to myself.

Oops, did I just type that out loud?


 It's the collective consciousness that is all the rage with the kids, and 
 that all the old adults (ourselves that are young now) think is too 
 fashionable/intrusive/dehumanizing/immoral/childish/not-childish/useless/wasteful/whatever-choose-your-own.

 Or not. :P

 PS: no offense intended. :)


Heh :) Damn Borg kids...

I think I'm basically turning into Cranky Kong (if you've ever played Donkey 
Kong Country):

"They can't keep this level of graphics up for much longer! We used to be 
lucky if we only got three shades of grey, let alone any real colors!"

"Look!...look at this!...as I rock, my beard swings! Waste of frames in my 
opinion!"



 Apr 07 2011



  parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail>  writes:


On 07/04/2011 21:21, Nick Sabalausky wrote:

 Heh :) Damn Borg kids...

 I think I'm basically turning into Cranky Kong (if you've ever played Donkey
 Kong Country):

 "They can't keep this level of graphics up for much longer! We used to be
 lucky if we only got three shades of grey, let alone any real colors!"

 "Look!...look at this!...as I rock, my beard swings! Waste of frames in my
 opinion!"


Are those actual quotes from the game? If so, hehe, pretty funny. :)

-- 
Bruno Medeiros - Software Engineer



 Apr 08 2011



  parent  "Nick Sabalausky" <a a.a>  writes:


"Bruno Medeiros" <brunodomedeiros+spam com.gmail> wrote in message 
news:inn2rl$2hp$2 digitalmars.com...

 On 07/04/2011 21:21, Nick Sabalausky wrote:

 Heh :) Damn Borg kids...

 I think I'm basically turning into Cranky Kong (if you've ever played 
 Donkey
 Kong Country):

 "They can't keep this level of graphics up for much longer! We used to be
 lucky if we only got three shades of grey, let alone any real colors!"

 "Look!...look at this!...as I rock, my beard swings! Waste of frames in 
 my
 opinion!"


 Are those actual quotes from the game? If so, hehe, pretty funny. :)


According to a Wiki I found, yea. I don't entirely remember though, it's 
been awhile. But he definitely says some things along those general lines. 
All while rocking in his chair and swinging his cane at you.



 Apr 08 2011



prev sibling  parent reply Daniel Gibson <metalcaedes gmail.com>  writes:


Am 05.04.2011 22:49, schrieb Nick Sabalausky:

 "Daniel Gibson" <metalcaedes gmail.com> wrote in message 
 news:infu1q$6bn$1 digitalmars.com...

 Am 05.04.2011 22:20, schrieb Jacob Carlborg:

 I'm referring to Firefox 4. What's the "AwfulBar" ?


 Probably the "Awesomebar".. the feature in FF3+ that searches all
 visisted URLs (and the page titles) for the word you type into the
 URL-bar (and not just completes URLs like before).
 http://blog.mozilla.com/blog/2008/04/21/a-little-something-awesome-about-firefox-3/


 
 Yea, it's also really, really ugly. 
 


"We didn't have it in the 90s so we don't need it now" :P

However: The awesomebar search feature can be deactivated with
browser.urlbar.matchOnlyTyped = false in about:config and the old look
can be brought back with
https://addons.mozilla.org/en-US/firefox/addon/oldbar/ .

Cheers,
- Daniel



 Apr 05 2011



  parent  "Nick Sabalausky" <a a.a>  writes:


"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:infvsb$6bn$2 digitalmars.com...

 Am 05.04.2011 22:49, schrieb Nick Sabalausky:

 "Daniel Gibson" <metalcaedes gmail.com> wrote in message
 news:infu1q$6bn$1 digitalmars.com...

 Am 05.04.2011 22:20, schrieb Jacob Carlborg:

 I'm referring to Firefox 4. What's the "AwfulBar" ?


 Probably the "Awesomebar".. the feature in FF3+ that searches all
 visisted URLs (and the page titles) for the word you type into the
 URL-bar (and not just completes URLs like before).
 http://blog.mozilla.com/blog/2008/04/21/a-little-something-awesome-about-firefox-3/


 Yea, it's also really, really ugly.


 "We didn't have it in the 90s so we don't need it now" :P


We didn't have D in the 90's, and I may very well have abandoned programming 
had I not come across it.


 However: The awesomebar search feature can be deactivated with
 browser.urlbar.matchOnlyTyped = false in about:config and the old look
 can be brought back with
 https://addons.mozilla.org/en-US/firefox/addon/oldbar/ .


matchOnlyTyped only affects part of the changed behavior, and I already have 
to have way too damn many "addons" (read: "third party hacks") just to make 
FF usable. Fuck, am I really *expected* to like or put up with something 
just people other people like it? Forget the 90's, this is "1984".



 Apr 05 2011



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2011-04-05 22:25, Daniel Gibson wrote:

 Am 05.04.2011 22:20, schrieb Jacob Carlborg:

 I'm referring to Firefox 4. What's the "AwfulBar" ?


 Probably the "Awesomebar".. the feature in FF3+ that searches all
 visisted URLs (and the page titles) for the word you type into the
 URL-bar (and not just completes URLs like before).
 http://blog.mozilla.com/blog/2008/04/21/a-little-something-awesome-about-firefox-3/

 I personally like it.


Ah, that one. I like it too.

-- 
/Jacob Carlborg



 Apr 05 2011



prev sibling  parent reply Lutger Blijdestijn <lutger.blijdestijn gmail.com>  writes:


Nick Sabalausky wrote:


 "Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message
 news:mailman.3178.1301970383.4748.digitalmars-d puremagic.com...

 On 4/5/11, Nick Sabalausky <a a.a> wrote:

 After all, I
 *really* want to get around to making my own web browser (based off
 either
 Mozilla or Chromium) - I'm getting really fed up with the current state
 of
 available web browsers. Well, and the web as a whole (god I fucking hate
 the
 web), but one step at a time, I guess).


 I'll be the first to install it.

 Btw, there's a full web browser example in the QtD sources. But it has
 to be ported to D2. And then you have to deal with any eventual bugs
 along the way. :]


 
 Ha! I may not need to do much after all: I was just looking through
 Wikipedia's giant list of browsers, found a few that looked potentially
 promising, tried them all and...well, was mostly disappointed. But the
 *last* one I had left to try I've been really impressed with so far:
 
 Arora (Qt/WebKit)
 http://code.google.com/p/arora/
 
 I've only tried it breifly, but the UI is *actually nice*! Only modern
 browser out there with a UI that isn't absolutely horrid. I didn't even
 see *one* instance of invisible-text on my light-on-dark system, which is
 unbeleivavly rare among all software these days.
 
 And it has a lot of essential stuff built in, like ad blocking,
 disableable JS, and a "ClickToFlash" which I haven't tried out yet.
 There's still a few things it seems like it might be missing, like
 equivalents to NoScript, BetterPrivacy and maybe DownloadHelper and
 DownThemAll, but most of those are less important to me, and even as it is
 right now it's a damn good start. Maybe I could add some of that remaining
 stuff, or heck, maybe even port the whole thing to D ;)


Even it it would involve looking at C++ code?

Did you know Arora *is* the Qt webbrowser example that got out of control  
and became a real browser? (it uses webkit)

iirc QtD has a sizeable chunk of that example already ported to D.



 Apr 06 2011



  parent  "Nick Sabalausky" <a a.a>  writes:


"Lutger Blijdestijn" <lutger.blijdestijn gmail.com> wrote in message 
news:inhp3g$25jq$1 digitalmars.com...

 Nick Sabalausky wrote:


 Ha! I may not need to do much after all: I was just looking through
 Wikipedia's giant list of browsers, found a few that looked potentially
 promising, tried them all and...well, was mostly disappointed. But the
 *last* one I had left to try I've been really impressed with so far:

 Arora (Qt/WebKit)
 http://code.google.com/p/arora/

 I've only tried it breifly, but the UI is *actually nice*! Only modern
 browser out there with a UI that isn't absolutely horrid. I didn't even
 see *one* instance of invisible-text on my light-on-dark system, which is
 unbeleivavly rare among all software these days.

 And it has a lot of essential stuff built in, like ad blocking,
 disableable JS, and a "ClickToFlash" which I haven't tried out yet.
 There's still a few things it seems like it might be missing, like
 equivalents to NoScript, BetterPrivacy and maybe DownloadHelper and
 DownThemAll, but most of those are less important to me, and even as it 
 is
 right now it's a damn good start. Maybe I could add some of that 
 remaining
 stuff, or heck, maybe even port the whole thing to D ;)


 Even it it would involve looking at C++ code?


Heh :) Yea, well, versus coding a whole browser from scratch that included 
all the features I'd want... Even using premade rendering and JS engines 
(which I definitely would have done), that still leaves a lot of work.


 Did you know Arora *is* the Qt webbrowser example that got out of control
 and became a real browser? (it uses webkit)


Yea, I noticed that on Arora's project page. Pretty cool.


 iirc QtD has a sizeable chunk of that example already ported to D.


I'm really interestng in looking at that now. I wonder how much of a split 
there is between that and the current Arora.



 Apr 06 2011



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2011-04-05 04:26, Andrej Mitrovic wrote:

 On 4/5/11, Nick Sabalausky<a a.a>  wrote:

 After all, I
 *really* want to get around to making my own web browser (based off either
 Mozilla or Chromium) - I'm getting really fed up with the current state of
 available web browsers. Well, and the web as a whole (god I fucking hate the
 web), but one step at a time, I guess).


 I'll be the first to install it.

 Btw, there's a full web browser example in the QtD sources. But it has
 to be ported to D2. And then you have to deal with any eventual bugs
 along the way. :]


DWT also has support for embedded web browsers. Although I'm not sure if 
it works or not.

-- 
/Jacob Carlborg



 Apr 05 2011



prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 4/4/11 8:36 PM, Nick Sabalausky wrote:

 "Daniel Gibson"<metalcaedes gmail.com>  wrote in message
 news:inddni$kmi$3 digitalmars.com...

 I don't know if wee need yet another GUI library.
 Are you sure Qt and DWT aren't good enough?


 AIUI:

 DWT doesn't support D2 (neither does wxD).


I understand DWT does support D2 on Windows as of today:

http://hg.dsource.org/projects/dwt2/rev/9f4c18c268b2


Andrei



 Apr 04 2011



  parent  "Nick Sabalausky" <a a.a>  writes:


"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:ine1bu$14mv$1 digitalmars.com...

 On 4/4/11 8:36 PM, Nick Sabalausky wrote:

 "Daniel Gibson"<metalcaedes gmail.com>  wrote in message
 news:inddni$kmi$3 digitalmars.com...

 I don't know if wee need yet another GUI library.
 Are you sure Qt and DWT aren't good enough?


 AIUI:

 DWT doesn't support D2 (neither does wxD).


 I understand DWT does support D2 on Windows as of today:

 http://hg.dsource.org/projects/dwt2/rev/9f4c18c268b2


Neat-o.

(I think I need some new superlatives...)



 Apr 04 2011



prev sibling next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-04-05 03:36, Nick Sabalausky wrote:

 "Daniel Gibson"<metalcaedes gmail.com>  wrote in message
 news:inddni$kmi$3 digitalmars.com...

 I don't know if wee need yet another GUI library.
 Are you sure Qt and DWT aren't good enough?


 AIUI:

 DWT doesn't support D2 (neither does wxD).


The Windows port now works with D2. Working on the Linux port.


 QtD requires a patched DMD, MinGW (which is fucking god-awful), and cmake (I
 have to let some variant of "make" touch my computer? Why can't we just let
 make die?). And it requires running your code through a preprocessor.

 And none of those have actual API documentation, they just refer to the
 C/C++ docs. I use D because I never want to look at another line of C++ as
 long as I live.


SWT is written in Java :)


 Everything else is either non-native or non-cross-platform.

 The state of GUIs in D right now is pretty awful, unfortunately. My plate's
 already overpacked (think: teenager at a one-trip buffet), but maybe I'll
 see if I can squeeze in enough extra time (hah! there's a concept I've
 completely lost all memory of) to try to help out on something. After all, I
 *really* want to get around to making my own web browser (based off either
 Mozilla or Chromium) - I'm getting really fed up with the current state of
 available web browsers. Well, and the web as a whole (god I fucking hate the
 web), but one step at a time, I guess).



-- 
/Jacob Carlborg



 Apr 05 2011



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Jacob Carlborg" <doob me.com> wrote in message 
news:inen8g$2cec$1 digitalmars.com...

 On 2011-04-05 03:36, Nick Sabalausky wrote:

 "Daniel Gibson"<metalcaedes gmail.com>  wrote in message
 news:inddni$kmi$3 digitalmars.com...

 I don't know if wee need yet another GUI library.
 Are you sure Qt and DWT aren't good enough?


 AIUI:

 DWT doesn't support D2 (neither does wxD).


 The Windows port now works with D2. Working on the Linux port.


Yea, I just saw another post mentioning that. That's awesome :)


 QtD requires a patched DMD, MinGW (which is fucking god-awful), and cmake 
 (I
 have to let some variant of "make" touch my computer? Why can't we just 
 let
 make die?). And it requires running your code through a preprocessor.

 And none of those have actual API documentation, they just refer to the
 C/C++ docs. I use D because I never want to look at another line of C++ 
 as
 long as I live.


 SWT is written in Java :)


Oh yea, that's right :)



 Apr 05 2011



  parent  Jacob Carlborg <doob me.com>  writes:


On 2011-04-05 12:28, Nick Sabalausky wrote:

 "Jacob Carlborg"<doob me.com>  wrote in message
 news:inen8g$2cec$1 digitalmars.com...

 On 2011-04-05 03:36, Nick Sabalausky wrote:

 "Daniel Gibson"<metalcaedes gmail.com>   wrote in message
 news:inddni$kmi$3 digitalmars.com...

 I don't know if wee need yet another GUI library.
 Are you sure Qt and DWT aren't good enough?


 AIUI:

 DWT doesn't support D2 (neither does wxD).


 The Windows port now works with D2. Working on the Linux port.


 Yea, I just saw another post mentioning that. That's awesome :)


 QtD requires a patched DMD, MinGW (which is fucking god-awful), and cmake
 (I
 have to let some variant of "make" touch my computer? Why can't we just
 let
 make die?). And it requires running your code through a preprocessor.

 And none of those have actual API documentation, they just refer to the
 C/C++ docs. I use D because I never want to look at another line of C++
 as
 long as I live.


 SWT is written in Java :)


 Oh yea, that's right :)


Except for the bindings to the native functions which is written in C 
with JNI but there's no reason to look at those.

-- 
/Jacob Carlborg



 Apr 05 2011



prev sibling  parent  =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Nick Sabalausky wrote:

 AIUI:

 DWT doesn't support D2 (neither does wxD).


wxD should compile/work with D2, it just doesn't "support" it...
Similar goes for using Tango rather than Phobos with it, as well.


 QtD requires a patched DMD, MinGW (which is fucking god-awful), and cmake (I
 have to let some variant of "make" touch my computer? Why can't we just let
 make die?). And it requires running your code through a preprocessor.


I thought QtD was already the "official" GUI for D2, just like
DWT for D1. Which seemed to imply those patches getting included.

--anders



 Apr 05 2011



prev sibling next sibling parent reply Adam Ruppe <destructionator gmail.com>  writes:


I've been slowly writing one of my own too. Used it to write
one real app, but that's all so far, and I only add functions
as I need them, so it's pretty minimal.

What I did to get a faster start is to tie it into Qt, with an
escape valve into qt if needed (also let me use Qt Designer!)
 while having some D niceties like property syntax, connecting signals
 to anonymous delegates, etc.

(For this app, I tried QtD first, but it kept crashing on Windows,
and I didn't have time to spare to fix it myself. Besides, qtd is a
huge set of libraries to distribute. Qt is big enough already, didn't
want to double the download by including qtd too.)


An approach like this might be good for your project too.



 Apr 04 2011



  parent  Adam Ruppe <destructionator gmail.com>  writes:


Oops, forgot to tell what the approach actually was!

The Qt part is written in C++ and compiled into a dll. The D
part links to this and passes messages to it across a series of
extern(c) functions.

Some messages are pretty high level and others are low level - whatever
I needed to get the app working with a minimal of C++.



 Apr 04 2011



prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com>  writes:


On 2011-04-04 17:27:05 -0400, Matthias Pleh <jens konrad.net> said:


 I would like to fill this gap and create a really good D GUI library
 
 Any thoughts, comments ... ?


Just an observation...

Cross platform libraries are fine, but they generally aren't very great 
either. They'll always stretch in one way or another the standard way 
to do things when put on a given platform. The end result will almost 
always look substandard when using that library in the environment it 
was not primarily designed for.

On the other hand, one thing that is missing right now, in D and in 
most languages, is a standard way to display graphics. By that I mean 
if we had in Phobos a module that could just open a window and let you 
draw things in it, it'd make learning programming much more fun and 
it'd be useful for rapid prototyping of anything that involves 
graphics. It doesn't need to be complicated -- it doesn't even need to 
have a GUI -- just drawing things and viewing them somewhere on a 
screen would be great. Later on you can add click support, full screen 
mode and other features if deemed useful, but the goal would never be 
provide bindings for every piece of GUI on all platforms.

So my observation is that a cross platform full-featured GUI will 
always fail somewhere (mostly where those platforms differs) whereas a 
cross platform drawing module with display capabilities is much more 
universally useful, is more easily approachable, and is much less code 
to maintain.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/



 Apr 04 2011



 next sibling parent reply Adam Ruppe <destructionator gmail.com>  writes:


Michel Fortin wrote:

 On the other hand, one thing that is missing right now, in D and in
 most languages, is a standard way to display graphics.


Actually, I wrote something to do that last year, but I thought
it was too trivial to share.

What you do is just draw some RGB stuff to a big memory buffer. Then
you can save as bmp, png, or create a window to display it.

There was no interaction with the window, except closing it. You'd
pop up the window so the user can review the picture, then he closes
it and your program continues where it left off.

Changing it to allow some updating and interaction shouldn't be
too hard.

It worked for both win32 and x11, no libraries required.


The reason I wrote it was that I really miss the simplicity of DOS
programming, where with just a few lines of inline asm, you have
a dead-simple video buffer to play with.



 Apr 04 2011



  parent reply Michel Fortin <michel.fortin michelf.com>  writes:


On 2011-04-04 19:55:44 -0400, Adam Ruppe <destructionator gmail.com> said:


 Michel Fortin wrote:

 On the other hand, one thing that is missing right now, in D and in
 most languages, is a standard way to display graphics.


 
 Actually, I wrote something to do that last year, but I thought
 it was too trivial to share.
 
 What you do is just draw some RGB stuff to a big memory buffer. Then
 you can save as bmp, png, or create a window to display it.
 
 There was no interaction with the window, except closing it. You'd
 pop up the window so the user can review the picture, then he closes
 it and your program continues where it left off.
 
 Changing it to allow some updating and interaction shouldn't be
 too hard.
 
 It worked for both win32 and x11, no libraries required.


Reminds me of David Simcha's plot2kill, which also has such a layer on 
top of which it implements plot drawing.
<http://www.dsource.org/projects/plot2kill>



 The reason I wrote it was that I really miss the simplicity of DOS
 programming, where with just a few lines of inline asm, you have
 a dead-simple video buffer to play with.


Indeed. Today you generally have to pile up a lot of GUI code just to 
be able to draw a square; all the simplicity is lost and portability is 
hard.

I think such a module would be a great addition to Phobos.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/



 Apr 04 2011



 next sibling parent reply "Nick Sabalausky" <a a.a>  writes:


"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:indr8m$qfc$1 digitalmars.com...

 On 2011-04-04 19:55:44 -0400, Adam Ruppe <destructionator gmail.com> said:


 The reason I wrote it was that I really miss the simplicity of DOS
 programming, where with just a few lines of inline asm, you have
 a dead-simple video buffer to play with.


 Indeed. Today you generally have to pile up a lot of GUI code just to be 
 able to draw a square; all the simplicity is lost and portability is hard.


Even with SDL's D bindings?



 Apr 04 2011



 next sibling parent reply Michel Fortin <michel.fortin michelf.com>  writes:


On 2011-04-04 21:46:08 -0400, "Nick Sabalausky" <a a.a> said:


 "Michel Fortin" <michel.fortin michelf.com> wrote in message
 news:indr8m$qfc$1 digitalmars.com...

 On 2011-04-04 19:55:44 -0400, Adam Ruppe <destructionator gmail.com> said:
 

 The reason I wrote it was that I really miss the simplicity of DOS
 programming, where with just a few lines of inline asm, you have
 a dead-simple video buffer to play with.


 
 Indeed. Today you generally have to pile up a lot of GUI code just to be
 able to draw a square; all the simplicity is lost and portability is hard.


 
 Even with SDL's D bindings?


Don't know. What is the minimal code you have to write to open a window 
and draw a square with SDL?

Also, you have to download the library and link to it and keep the 
dynamic library around with the compiled program, which is some more 
hassle.

But you're right that SDL comes pretty close.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/



 Apr 04 2011



  parent  "Nick Sabalausky" <a a.a>  writes:


"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:indtda$trl$1 digitalmars.com...

 On 2011-04-04 21:46:08 -0400, "Nick Sabalausky" <a a.a> said:


 "Michel Fortin" <michel.fortin michelf.com> wrote in message
 news:indr8m$qfc$1 digitalmars.com...

 On 2011-04-04 19:55:44 -0400, Adam Ruppe <destructionator gmail.com> 
 said:


 The reason I wrote it was that I really miss the simplicity of DOS
 programming, where with just a few lines of inline asm, you have
 a dead-simple video buffer to play with.


 Indeed. Today you generally have to pile up a lot of GUI code just to be
 able to draw a square; all the simplicity is lost and portability is 
 hard.


 Even with SDL's D bindings?


 Don't know. What is the minimal code you have to write to open a window 
 and draw a square with SDL?


I'm not really sure. I've been sinking in the web-dev quicksand/firepits so 
long I've never really had a chance to actually use SDL in D, and I don't 
remember any of SDL's API.


 Also, you have to download the library and link to it and keep the dynamic 
 library around with the compiled program, which is some more hassle.

 But you're right that SDL comes pretty close.





 Apr 04 2011



prev sibling  parent  Adam D. Ruppe <destructionator gmail.com>  writes:


Nick Sabalausky wrote:

 Even with SDL's D bindings?


Yea, even SDL is pretty far from as nice as DOS was. But, it isn't
too bad. D's bindings are identical to C's, but with things like
scope guard, it's a lot easier to use.

Long before D2 was around, I made a little game library in D1 using
SDL and OpenGL. Was able to whip up a Pong in about 100 lines and
a RTS in ~8000!

But, that library forced a certain style on you. Make a class with
a method that's called once per frame. You simply do a scope
painter class and draw your stuff.

Pretty cool. I'm hoping to clean it up and port to D2 eventually,
but I haven't had time to write games for a long time now.



 Apr 04 2011



prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


Michel Fortin:

 Reminds me of David Simcha's plot2kill, which also has such a layer
 on top of which it implements plot drawing.


Aye, he and I have shared some code in the past.


 I think such a module would be a great addition to Phobos.


If I can find a weekend, I'll see about quickly whipping it together
for a proposal. I don't know anything about Mac OSX though, so unless
the X11 will work there, I won't be able to provide any access to
that.



 Apr 04 2011



 next sibling parent  Jacob Carlborg <doob me.com>  writes:


On 2011-04-05 04:39, Adam D. Ruppe wrote:

 Michel Fortin:

 Reminds me of David Simcha's plot2kill, which also has such a layer
 on top of which it implements plot drawing.


 Aye, he and I have shared some code in the past.


 I think such a module would be a great addition to Phobos.


 If I can find a weekend, I'll see about quickly whipping it together
 for a proposal. I don't know anything about Mac OSX though, so unless
 the X11 will work there, I won't be able to provide any access to
 that.


X11 will work but I think it's not worth it if it isn't native. But 
maybe someone else could contribute with a Mac OS X version.

-- 
/Jacob Carlborg



 Apr 05 2011



prev sibling  parent  Matthias Pleh <jens konrad.net>  writes:


Am 05.04.2011 04:39, schrieb Adam D. Ruppe:

 Michel Fortin:

 Reminds me of David Simcha's plot2kill, which also has such a layer
 on top of which it implements plot drawing.


 Aye, he and I have shared some code in the past.


 I think such a module would be a great addition to Phobos.


 If I can find a weekend, I'll see about quickly whipping it together
 for a proposal. I don't know anything about Mac OSX though, so unless
 the X11 will work there, I won't be able to provide any access to
 that.


Yeah, would be cool if you could do that. I would like to write such a 
proposal myself, but since english is not my native language, it's 
better somone else do it. :)

°Matthias



 Apr 05 2011



prev sibling next sibling parent  dsimcha <dsimcha yahoo.com>  writes:


On 4/4/2011 9:25 PM, Michel Fortin wrote:

 On 2011-04-04 19:55:44 -0400, Adam Ruppe <destructionator gmail.com> said:


 Michel Fortin wrote:

 On the other hand, one thing that is missing right now, in D and in
 most languages, is a standard way to display graphics.


 Actually, I wrote something to do that last year, but I thought
 it was too trivial to share.

 What you do is just draw some RGB stuff to a big memory buffer. Then
 you can save as bmp, png, or create a window to display it.

 There was no interaction with the window, except closing it. You'd
 pop up the window so the user can review the picture, then he closes
 it and your program continues where it left off.

 Changing it to allow some updating and interaction shouldn't be
 too hard.

 It worked for both win32 and x11, no libraries required.


 Reminds me of David Simcha's plot2kill, which also has such a layer on
 top of which it implements plot drawing.
 <http://www.dsource.org/projects/plot2kill>



Right.  Plot2kill defines an abstraction layer over the drawing 
functionality of a GUI library (lines, rectangles, text, etc.), so that 
the code for drawing a plot is strongly decoupled from the GUI library. 
  So far this has proven successful on GtkD and DFL.

However, Plot2kill also defines a default plot window, which allows for 
things like saving the plot interactively, zooming in on subplots and, 
in the GtkD incarnation, customizing several aspects of the plot 
interactively.  For this stuff, I didn't even try to abstract away the 
GUI library because it seemed self-evident to me that creating this 
massive and brittle an adapter layer was a bad idea, and the lesser of 
two evils would be to just write an independent default plot window for 
each library.



 Apr 04 2011



prev sibling  parent reply Matthias Pleh <jens konrad.net>  writes:


Am 05.04.2011 03:25, schrieb Michel Fortin:

 On 2011-04-04 19:55:44 -0400, Adam Ruppe <destructionator gmail.com> said:


 Michel Fortin wrote:

 On the other hand, one thing that is missing right now, in D and in
 most languages, is a standard way to display graphics.


 Actually, I wrote something to do that last year, but I thought
 it was too trivial to share.

 What you do is just draw some RGB stuff to a big memory buffer. Then
 you can save as bmp, png, or create a window to display it.

 There was no interaction with the window, except closing it. You'd
 pop up the window so the user can review the picture, then he closes
 it and your program continues where it left off.

 Changing it to allow some updating and interaction shouldn't be
 too hard.

 It worked for both win32 and x11, no libraries required.


 Reminds me of David Simcha's plot2kill, which also has such a layer on
 top of which it implements plot drawing.
 <http://www.dsource.org/projects/plot2kill>



 The reason I wrote it was that I really miss the simplicity of DOS
 programming, where with just a few lines of inline asm, you have
 a dead-simple video buffer to play with.


 Indeed. Today you generally have to pile up a lot of GUI code just to be
 able to draw a square; all the simplicity is lost and portability is hard.

 I think such a module would be a great addition to Phobos.


 Michael
Your right. That's what I've tried to say in my other thread. Just a 
_standard_ way to display graphics. This could be a base for other works.

 Adam
Have you some code around, which we can push further?


°Matthias



 Apr 05 2011



  parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


Matthias Pleh wrote:

 Have you some code around, which we can push further?


Yeah, I'm porting one of the C components to D, then will post it
here.

(The D headers weren't good enough and I got lazy when copying them
over and decided to just write a couple of the functions in C instead.
I've already moved the X11 over to D, now need to do the same to
the Windows side.)



 Apr 05 2011



  parent reply Matthias Pleh <jens konrad.net>  writes:


Am 05.04.2011 23:50, schrieb Adam D. Ruppe:

 Matthias Pleh wrote:

 Have you some code around, which we can push further?


 Yeah, I'm porting one of the C components to D, then will post it
 here.

 (The D headers weren't good enough and I got lazy when copying them
 over and decided to just write a couple of the functions in C instead.
 I've already moved the X11 over to D, now need to do the same to
 the Windows side.)



Are you talking about the dImage project, with the display-X11/win32 
backends, on you side?



 Apr 05 2011



  parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


Matthias Pleh wrote:

 Are you talking about the dImage project, with the display-X11/win32
 backends, on you side?


Yeah, that's the original version. I just finished doing the Windows
side (wasn't as bad as I thought) and put it all in one module. This
simplified version has no file format support yet.

http://arsdnet.net/dcode/simpledisplay.d

Usage example:

====

import simpledisplay;

void main() {
	auto image = new Image(255, 255);

	foreach(a; 0..255)
	foreach(b; 0..255)
		image.putPixel(a, b, Color(a, b, 0));

	image.display();
}

====

To compile:

dmd test.d simpleimage.d

Should work on both Windows and Linux the same way.



 Apr 05 2011



 next sibling parent  Adam D. Ruppe <destructionator gmail.com>  writes:


I need to run, so must be fast.

You'll note my code is ugly as sin and includes a good chunk
of xlib.h right in there... ideally, I'd like xlib to be in
etc.x11.xlib or something like that instead of here. Until it is
though, it will stay so it's a self-contained module.

Anyway, where I'd ultimately like to take this is to provide the
same simple set of functions we used to enjoy on DOS:

1) Simple shape drawing. Lines, rectangles, filled boxes, circles, etc.

2) Keep the output dead simple, or let you have an interactive
window that you can draw to and get some input from. Should keep
a very simple flow (while(int 16h) kind of thing).

This could be determined by an optional param to the display()
method.

3) Image loading and saving, so you can draw sprites too.


I think that's about everything. No widgets, no frameworks, just
shooting for super simple, very basic functions.



 Apr 05 2011



prev sibling next sibling parent  Matthias Pleh <jens konrad.net>  writes:


Am 06.04.2011 00:20, schrieb Adam D. Ruppe:

 import simpledisplay;

 void main() {
 	auto image = new Image(255, 255);

 	foreach(a; 0..255)
 	foreach(b; 0..255)
 		image.putPixel(a, b, Color(a, b, 0));

 	image.display();
 }


Hey cool, this was a fast fix.
Thank's for sharing!


°Matthias



 Apr 05 2011



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:ing4ir$260f$1 digitalmars.com...

 Matthias Pleh wrote:

 Are you talking about the dImage project, with the display-X11/win32
 backends, on you side?


 Yeah, that's the original version. I just finished doing the Windows
 side (wasn't as bad as I thought) and put it all in one module. This
 simplified version has no file format support yet.

 http://arsdnet.net/dcode/simpledisplay.d

 Usage example:

 ====

 import simpledisplay;

 void main() {
 auto image = new Image(255, 255);

 foreach(a; 0..255)
 foreach(b; 0..255)
 image.putPixel(a, b, Color(a, b, 0));

 image.display();
 }

 ====

 To compile:

 dmd test.d simpleimage.d

 Should work on both Windows and Linux the same way.


I haven't benchmarked or even tested this, and heck, maybe I'm just a 
dinosaur, but for better speed and flexibility I'd recommend something more 
like what I've attached. For reasons that should be apparent in the code, 
this would need to be compiled with -inline, which in turn will most likely 


void main() {
    auto image = new Image!(255, 255);

    foreach(a; 0..image.width)
    foreach(b; 0..image.height)
        image.fast[a, b] = Color(a, b, 0);

    foreach(x; 128...999)
        image.crop[x, 128] = image.crop[x, 64];

    image.fast[10, 10] = Color(0xFFFFFF_FF);

    // Set the blue component of a pixel
    // Some API func could be added for this
    auto i = image.fast.indexAt(20, 20) * 4 + 2;
    (cast(ubyte[])image.data)[i] = 0xCC;

    image.display();
}

The main under-the-hood changes:

- The width is statically-known, so the compiler can optimize the index 
calculation from multiplication to shifts when appropriate. The height being 
statically-known might help slightly, too.

- In release mode, using a non-cropped version is faster than cropped (good 
for when you know you won't exceed the bounds).

- Setting/getting a pixel is a one-write (or one-read) 32-bit-aligned 
operation. Ie, faster, of course.

- IIRC, 32-bit framebuffers are a little more typical, so the image data 
should be more likely to be usable without conversion.

- The alpha channel opens the door for, well, mixing images using alpha.

A major improvement, of course, would be to replace the GDI stuff with 
Direct3D 7 or 8 (there's no real need to require anything beyond those 
versions). It's would be a non-trivial change of course, but once done it 
would be a huge improvement.

I really had fun with this :) This is the sort of thing I grew up on. And D 
suits it so much better than any other language I've used.



begin 666 simpleDisplayMod.d

M+"!I<R!T:&ES('-T:6QL(&EM<&QI8VET;'D 9&5F:6YE9"!W:&5N('1H92!O

M=&AI<RYD871A(#T


M('5B>71E(&(L('5B>71E(&$I('L-" D)=&AI<RYD871A(#T *'( /#P ,C0I
M('P *&< /#P ,38I('P *&( /#P ."D ?"!A.PT*"7T-" D-" E <')O<&5R



M>2!R968 =6)Y=&4 8B I('L-" D)<F5T=7)N("AC87-T*'5B>71E6S1=*61A




M9'1H+"!I;G0 7VAE:6=H="D :68H7W=I9'1H(#X

M($EM86=E(&-A;B!D971E<FUI;F4 =&AE('=I9'1H+VAE:6=H= T*"65N=6T 
M=VED=&  (#T 7W=I9'1H.PT*"65N=6T :&5I9VAT(#T 7VAE:6=H=#L-" T*
M"4-O;&]R6UT 9&%T83L-" D-" DO+R\ 4F5T=7)N960 8GD 8W)O<"YO<$EN
M9&5X(&EF('1H92!C;V]R9&EN871E<R!A<F4 ;W5T+6]F+6)O=6YD<PT*"4-O


M=$-O;&]R.PT*"0ED871A+FQE;F=T:" ]('=I9'1H("H :&5I9VAT.PT*"7T-
M" T*"7!R:79A=&4 <W1A=&EC('-T<FEN9R!E<G)O<D]U=$]F0F]U;F1S*&EN
M="!X+"!I;G0 >2D >PT*"0ET:')O=R!N97< 17AC97!T:6]N* T*"0D)=&5X
M=" B3W5T(&]F(&)O=6YD<SH 4VEZ92 B+'=I9'1H+"(L(BQH96EG:'0L(BD 


M?"!X(#X]('=I9'1H('Q\('D /" P('Q\('D /CT :&5I9VAT.PT*"7T-" D-

M="!A<F4 ;W5T+6]F+6)O=6YD<R!A<F4 8W)O<'!E9 T*"7!R:79A=&4 <W1R
M=6-T($-R;W  >PT*"0D-" D)<W1A=&EC('-I>F5?="!I;F1E>$%T*&EN="!X
M+"!I;G0 >2D >PT*"0D):68H:7-);D)O=6YD<RAX+"!Y*2D-" D)"0ER971U




M>"P <VEZ95]T('DI('L-" D)"61A=&%;:6YD97A!="AX+"!Y*5T /2!C.PT*

M=6< ;6]D93H 3W5T+6]F+6)O=6YD<R!A8V-E<W, =&AR;W=S+ T*"2\O+R!)
M;B!R96QE87-E(&UO9&4Z($]U="UO9BUB;W5N9', 86-C97-S(&UI9VAT('1H


M="!X+"!I;G0 >2D >PT*"0D)9&5B=6< :68H:7-);D)O=6YD<RAX+"!Y*2D-

M0V]L;W( ;W!);F1E>"AS:7IE7W0 >"P <VEZ95]T('DI('L-" D)"7)E='5R





M*0T*"69O<F5A8V H8CL ,"XN:6UA9V4N:&5I9VAT*0T*"0EI;6%G92YF87-T
M6V$L(&)=(#T
M+CDY.2D-" D):6UA9V4N8W)O<%MX+" Q,CA=(#T :6UA9V4N8W)O<%MX+" V






`
end



 Apr 05 2011



  parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


Note: I just updated my simpledisplay.d. My color constructor
said b = c when I meant this.b = c... hence everything was yellow!
You can download again from the same place.

Nick Sabalausky wrote:

 I haven't benchmarked or even tested this, and heck, maybe I'm just
 a dinosaur, but for better speed and flexibility I'd recommend
 something more like what I've attached.


Yea, that does sound better. Though I have a few comments...


 The width is statically-known, so the compiler can optimize the
 index calculation from multiplication to shifts when appropriate.


One concern I have here is will it be an incompatible type with
dynamic widths? i.e. an image loaded from a file? (I'll be hopefully
cleaning up my png and bmp loaders in the near future to use with
this.)

Maybe it could use an interface to smooth that over.

I actually had a similar fight with myself over Indexed vs TrueColor
when writing the original thing. They really don't have compatible
interfaces. Sure, you could do some kind of putpixel(uint data)
for each of them, but it's not really the same.

So I think they should be separate types, with functions to convert
back and forth. (both conversions being lossy in their own way..
just because two palette entries have the same rgb values doesn't
mean the two colors are semantically the same.)


But, I'm getting off the point. Indexed images can be played with
later.


 The alpha channel opens the door for, well, mixing images using alpha.


Definitely.




 A major improvement, of course, would be to replace the GDI
 stuff with Direct3D 7 or 8 (there's no real need to require
 anything beyond those versions).


Now, I don't want to get too fancy.. especially since I've never
used directx, not even for hello world, and I don't think
performance will be too big of a deal.

But, I did do something similar with my D1 game lib. It uses
SDL for most its stuff, but I found that to be dreadfully slow
with anything beyond the simple, so I changed the output to
use OpenGL, set up to do 2d output. Only difference client code
wise was I had was I had to stop using putPixel - it was even
slower! But sprite rotation and blitting, lines, shapes, all that
stuff was sped up by huge, huge amounts.

And I got free alpha blending and gradients! It was a huge
benefit, ultimately very worth it.


So yeah, I think I would like to do something similar here too,
but since I have no experience with D3D it'll have to be low
on my own priority list. But I like the idea!



Now, the next thing I want to write up in here is some kind of
event handling. The idea is:

image.display(); // does what it does now - just make it work, and
                 // wait for the user to close the window.

This keeps it dead simple for a reporting use case. But, let's
think about some interactivity too.

In DOS, the pattern I used was something like this:

// initialize the program and the screen

while(still_going) {
    if(kbhit()) {
       char c = getch();
       // handle c
    }

    // draw your frame

    wait_for_next_frame();
}

// clean up



My D1 game code did something similar, but the loop was replaced
by a virtual class method and the wait was done by a system timer.
(And something too cool: instead of
checking the keyboard, it checked a joystick or keyboard, pretending
it always had a Playstation controller.


   // react
if(buttonIsDown(square))
   // react

Then, if you had a controller plugged into the computer, it'd
just work, or you could be boring and use the keyboard, with
the keys mapped to the playstation names.

One of the IMO best parts was that the controller interface was
also network transparent, so any game that stuck to it could
be played online too. The way that'd work is the server sends
out state to everyone, random number seeds, etc. Then, all
controls were lagged a frame or two. If you pressed a button, it'd
transmit your action to the other players along with a timestamp.

Frame 20, you hit circle. It sends down the network "on frame 22,

has the same program and the same initial state, everyone sees
the same thing, without the game itself needing to know anything
about the network.

Of course, the lag could be slightly annoying, but meh, didn't
bother me. Besides, I can't complain too much about free networking!


Man, I wish I had more time to make games.

Of course, there were also keyIsDown, etc, too if you couldn't
use the controller interface, but it didn't get the automatic
networking or different players.



Wow, I'm off topic again. Anyway, for the event loop here, I'm
thinking something similar to how std.concurrency does it might
be a good approach: a bunch of delegates, matched to events by
their signature. Simple signatures could be accepted as well
as fancier ones.

// need to make a simple window separately here so it is persistent
auto win = new DrawableWindow(width, height);

// still use an image the same way. Alternatively, DrawableWindow
// could implement the same interface as Image, probably double
// buffering internally anyway, so pretty much same implementation.
auto image = new Image(width, height);

window.eventLoop(
   50, // first parameter is the timeout. can be 0 to only react
       // to events, but putting one in gives you an easy to use
       // frame pulse for drawing
   (int keyPressed) { // might be a struct KeyEvent rather than int
        // react to the key
   },
   (int x, int y, int mouseButton) {
        // react to a mouse click
   },
   () { // no params means your timeout happened, time to draw
        // draw your frame...

        image.display(win); // this overload uses the existing
                            // window and returns immediately
                            // rather than making and waiting
   }
   // might also offer a platform specific msg, wParam, lParam
   // so you could in theory do all of Win32 based on this same
   // framework
);



This way, you could whip something up right there and have a
simple little game all inside a couple dozen lines of main()
without needing any monster libraries in your project.

Wow, I think I really like this...



 Apr 05 2011



 next sibling parent reply "Nick Sabalausky" <a a.a>  writes:


"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:ingldk$1r9$1 digitalmars.com...

 Nick Sabalausky wrote:

 The width is statically-known, so the compiler can optimize the
 index calculation from multiplication to shifts when appropriate.


 One concern I have here is will it be an incompatible type with
 dynamic widths? i.e. an image loaded from a file? (I'll be hopefully
 cleaning up my png and bmp loaders in the near future to use with
 this.)

 Maybe it could use an interface to smooth that over.


Anything that provides an abstraction for manipulating individual pixels 
needs to be *ultra* fast, zero overhead. So I don't think it would be a good 
idea to let any vtable overhead get into there. In fact, even the overhead 
of a function call is a big problem and the pixel-access routines really 
need to be inlined. I *think* with the class being final, calls to the 
pixel-access routines can have their vtable indirection optimized away and 
*should* be inline-able (if not, then they really should be turned into 
string mixins to force the inlining - although maybe not if it's *just* for 
toying around). But my understanding is that making the functions part of an 
interface will force the vtable overhead and definitely inhibit inlining.

My thought is this: Functions which take an Image should be templated on the 
image's type. Then, the image types can work the way ranges work: by using 
what's essentially compile-time duck-typing. Except, I hate the laxness of a 
duck's structural typing, so all the image types would include a static 
dummy variable named something like "_this_is_a_type_Image_", and the 
isImage template would check for that.

Then, some sort of adapter or converter could be created to go back and 
forth between static-sized and dynamic-sized images for any cases where you 
might really need to skip the templating (possibly at the cost of some 
speed, though). And that should take care of everything.

Actually, that pretty much describes the gist of an article I'm planning to 
write for that D article competition. Of course, if you see any fundamental 
problems with this, feel free to let me know :)


 But, I'm getting off the point. Indexed images can be played with
 later.


I'm nostalgic for palette-cycling effects :) VGA was great. (And I get 
downright excited over EGA.)


 A major improvement, of course, would be to replace the GDI
 stuff with Direct3D 7 or 8 (there's no real need to require
 anything beyond those versions).


 Now, I don't want to get too fancy.. especially since I've never
 used directx, not even for hello world, and I don't think
 performance will be too big of a deal.


GDI is notoriously bad for performance. It's good enough for desktop 
applications, and it's fine if you're just going to draw something once and 
display it. But for anything that's continuously drawing new frames GDI has 
never really cut it. That's what DirectX was made for in the first place. 
(Actually, that's what WinG was made for but even that *still* wasn't quite 
good enough and it was quickly replaced by the "Game SDK" which was renamed 
to DirectX at version 2. Now I feel old.) Although that said, I did once 

http://www.semitwist.com/download/GDIPac.zip

I have used DirectX, although it's been awhile (way back in my C/C++ days), 
and it was back when DirectDraw was still relevant. Direct3D is now the way 
to do high-performance 2D and 3D (unless you're requiring a new enough 
version of DirectX that you'd have access to Direct2D, but I don't remember 
which version introduced Direct2D.) Of course, OpenGL can be used too, but 
AIUI the average-Joe's Windows computer isn't likely to have reasonably good 
OpenGL drivers (unless my info's just out-of-date).


 But, I did do something similar with my D1 game lib. It uses
 SDL for most its stuff, but I found that to be dreadfully slow
 with anything beyond the simple, so I changed the output to
 use OpenGL, set up to do 2d output. Only difference client code
 wise was I had was I had to stop using putPixel - it was even
 slower!


Yea, any individual-pixel-access function is going to be overly slow unless 
it's completely inlined and highly optimized. And even then, things like 
line drawing, fills and image blitting are still better off skipping the 
individual-pixel-access routines (unless optimizing compilers have gotten 
far better than I'd even thought).

If you haven't already, any of the old books by Andre' LaMothe or Michael 
Abrash are fantastic resources for high-performance graphics processing in 
software. Oldies, but goodies.

But anyway, I don't know exactly how you were going about it, but the way to 
do this in OpenGL or DirectX would be to do all your drawing to a texture 
buffer (using the same pixel-format as the current screen mode), and attach 
that texture to couple of hardware-drawn triangles arranged in a rectangle. 
Then optionally wait for the VSync, and then render (or maybe better yet, 
render to a back buffer, wait for VSync, and then flip).


 But sprite rotation and blitting, lines, shapes, all that
 stuff was sped up by huge, huge amounts.

 And I got free alpha blending and gradients! It was a huge
 benefit, ultimately very worth it.


Yup. Hardware acceleration (ie, OpenGL or DirectX) is totally the way to go 
whenever possible.


 So yeah, I think I would like to do something similar here too,
 but since I have no experience with D3D it'll have to be low
 on my own priority list. But I like the idea!


I'd love to do some of this. It's been FAR too long since I've even touched 
anything remotely game-related. Maybe I'll have to make time for it. We'll 
see.


 In DOS, the pattern I used was something like this:

 // initialize the program and the screen

 while(still_going) {
    if(kbhit()) {
       char c = getch();
       // handle c
    }

    // draw your frame

    wait_for_next_frame();
 }

 // clean up


You were using getch() in a game? Much better to hook the keyboard interrupt 
handler, watch the scan codes, and update an array or bitfield containing 
the current up/down state of each key. Then the game code just checks the 
key status array. Much more responsive that way, and you get control over 
key-up/key-down.


 My D1 game code did something similar, but the loop was replaced
 by a virtual class method and the wait was done by a system timer.
 (And something too cool: instead of
 checking the keyboard, it checked a joystick or keyboard, pretending
 it always had a Playstation controller.


   // react
 if(buttonIsDown(square))
   // react

 Then, if you had a controller plugged into the computer, it'd
 just work, or you could be boring and use the keyboard, with
 the keys mapped to the playstation names.


I prefer to use a more general key mapping system: On one side, you have 
every key and button your game recognizes. On the other side you have things 
like "jump", "walk left", "walk right", "run", "context-sensitive action 
button", etc. Then you just connect the dots between the two sides. Makes 
user-configurability very easy. I suppose that's very similar to yours 
though, just using game-specific names instead of "triangle"/"square"/etc.

BTW, this is something I'd use DirectInput for. The Win32 event system is 
about as suitable for game input as the GDI is for game graphics.


 One of the IMO best parts was that the controller interface was
 also network transparent, so any game that stuck to it could
 be played online too. The way that'd work is the server sends
 out state to everyone, random number seeds, etc. Then, all
 controls were lagged a frame or two. If you pressed a button, it'd
 transmit your action to the other players along with a timestamp.

 Frame 20, you hit circle. It sends down the network "on frame 22,

 has the same program and the same initial state, everyone sees
 the same thing, without the game itself needing to know anything
 about the network.

 Of course, the lag could be slightly annoying, but meh, didn't
 bother me. Besides, I can't complain too much about free networking!


That's interesting. Not the way to do Halo obviously, but for simple stuff I 
can see how that would be nice and convenient.


 Man, I wish I had more time to make games.


I'd say "ditto", but that'd be one hell of an understatement. I used to be a 
huge regular ("Abscissa") over on the xgames3d forums (now xgamestation.com) 
even way back before it moved over to hardware. Heck, I even have one of the 
first usernames assigned there :) God I miss game dev. Don't want to join 
one of the established companies though. Don't like many of the directions 
the industry's been going the last ten years or so. And then dealing with 
crunches and studio closings, all just to make the next hollywood-wannabe 



 Wow, I'm off topic again. Anyway, for the event loop here, I'm
 thinking something similar to how std.concurrency does it might
 be a good approach: a bunch of delegates, matched to events by
 their signature. Simple signatures could be accepted as well
 as fancier ones.

 // need to make a simple window separately here so it is persistent
 auto win = new DrawableWindow(width, height);

 // still use an image the same way. Alternatively, DrawableWindow
 // could implement the same interface as Image, probably double
 // buffering internally anyway, so pretty much same implementation.
 auto image = new Image(width, height);

 window.eventLoop(
   50, // first parameter is the timeout. can be 0 to only react
       // to events, but putting one in gives you an easy to use
       // frame pulse for drawing
   (int keyPressed) { // might be a struct KeyEvent rather than int
        // react to the key
   },
   (int x, int y, int mouseButton) {
        // react to a mouse click
   },
   () { // no params means your timeout happened, time to draw
        // draw your frame...

        image.display(win); // this overload uses the existing
                            // window and returns immediately
                            // rather than making and waiting
   }
   // might also offer a platform specific msg, wParam, lParam
   // so you could in theory do all of Win32 based on this same
   // framework
 );



 This way, you could whip something up right there and have a
 simple little game all inside a couple dozen lines of main()
 without needing any monster libraries in your project.

 Wow, I think I really like this...


Interesting. I've had a lot of thoughts about game loops flying around in 
the back of my mind too, but talking about any of it will have to wait for 
another time, gotta get back to some other stuff right now...



 Apr 06 2011



  parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


Nick Sabalausky wrote:

 Of course, if you see any fundamental
 problems with this, feel free to let me know :)


I'm pretty sure your plan would work and would provide a boost,
but I'm not sure if it's worth the extra time.

I think the best thing to do will be to partially implement it,
write a little program with both methods and run some speed tests.
See if it's still easy to use and how big the difference really is.

I'm actually already almost to the point where the simple event
loop / gdi implementation works, so won't take long to finish
that off. Then we'll go back and see what to do with speed with
the simple base to compare against.


 It's good enough for desktop applications, and it's fine if
 you're just going to draw something once and display it.


Heh, that /was/ my original intention! But now, I think we can
go so much further.


 And even then, things like line drawing, fills and image
 blitting are still better off skipping the
 individual-pixel-access routines


Aye, even my homegrown DOS would always write them separately.
Horrible waste of instructions doing another y << 8 + y << 6 when
a simple "inc ax" would suffice!


 But anyway, I don't know exactly how you were going about it, but
 the way to do this in OpenGL or DirectX would be to do all your
 drawing to a texture buffer


I at first just used a SetPixel function in opengl, but when it
was unacceptable, I simply abandoned the idea of drawing pixels
to the screen. Instead, I started focusing on polygons and textures -
a rectangle with a bitmap attached as a texture makes an excellent
sprite that draws very very quickly, even if rotated or misshapen.

Once I realized that works so well, pixels weren't important
anymore so I just stopped using the old functions entirely. They're
still in the code, still godawfully slow, but I don't care enough
to change it.


 I'd love to do some of this.


Excellent!


 You were using getch() in a game?


Not literally, no, but this was quicker to write up in a post
than to dig up the old assembly and keymaps to paste it all in,
while still hopefully showing the same basic idea behind it.
(specifically that it was a simple loop rather than a callback
or virtual function system like most events nowadays)


 BTW, this is something I'd use DirectInput for. The Win32 event
 system is about as suitable for game input as the GDI is for game
 graphics.


All right. If you have the time to write that up too, I'd
appreciate it. I'll keep it simple now due to my lack of experience
with it. The one rule though is it needs to remain easy to use. One
idea here is that newbies can run with it quickly.


 Don't want to join one of the established companies though.


Oh, hell no. Especially since my preferred style is more NES than
XBox - I like the simple 2d, low resolution look. I like the
relatively low frame rate. There's a lot less pressure to code
it perfectly too (meaning I can just whip stuff out and it's good
enough as long as its fun).



 Interesting. I've had a lot of thoughts about game loops flying
 around in the back of my mind too, but talking about any of it
 will have to wait for another time, gotta get back to some other
 stuff right now


Yea, me too... I did start that eventLoop function last night
though. So far just tied in WM_KEYDOWN to a delegate, but it works
and it's easy, so I figure I'll continue to flesh it out for the
basic operations. This way, we can play with it soon and can go
back and switch to a better system later.



 Apr 06 2011



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:ini1jr$2lj3$1 digitalmars.com...

 Nick Sabalausky wrote:

 Of course, if you see any fundamental
 problems with this, feel free to let me know :)


 I'm pretty sure your plan would work and would provide a boost,
 but I'm not sure if it's worth the extra time.

 I think the best thing to do will be to partially implement it,
 write a little program with both methods and run some speed tests.
 See if it's still easy to use and how big the difference really is.



Yea, sounds like a good plan. Although, my design is heavily dependent on 

http://d.puremagic.com/issues/show_bug.cgi?id=5708

There another similar -inline related bug in there too, but I don't remember 
offhand what it is.


 And even then, things like line drawing, fills and image
 blitting are still better off skipping the
 individual-pixel-access routines


 Aye, even my homegrown DOS would always write them separately.
 Horrible waste of instructions doing another y << 8 + y << 6 when
 a simple "inc ax" would suffice!


Yup, exactly. Which reminds me, I've always wanted to actually check to see 
if modern compilers (or at least DMD) would be smart enough to optimize 
something like:

for(i in 128...256)
    arr[i] = ...;

Into something like:

auto ptr = arr.ptr + 128;
auto ptrEnd = arr.ptr + 256;
for(; ptr < ptrEnd; ptr++)
    *ptr = ...;

My guess is no (and I'm fairly certain it was "no" back in my DOS days: that 
was the sort of manual optimization I remember doing all the time), but with 
all the improvements that optimizers keep making, I'm not really sure 
anymore.

Of course, even if the compiler can optimize that, I still doubt it would be 
able to automatically do an equivalent optimization to effectively create, 
for example, Bresenham's algorithm (ie, straight diagonal lines between two 
arbitrary points).


 But anyway, I don't know exactly how you were going about it, but
 the way to do this in OpenGL or DirectX would be to do all your
 drawing to a texture buffer


 I at first just used a SetPixel function in opengl, but when it
 was unacceptable, I simply abandoned the idea of drawing pixels
 to the screen. Instead, I started focusing on polygons and textures -
 a rectangle with a bitmap attached as a texture makes an excellent
 sprite that draws very very quickly, even if rotated or misshapen.

 Once I realized that works so well, pixels weren't important
 anymore so I just stopped using the old functions entirely. They're
 still in the code, still godawfully slow, but I don't care enough
 to change it.


Yea. I see. I wonder if OpenGL's SetPixel was inlined. If not, I bet we 
could do better (as long as we had direct access to the texture's buffer).


 You were using getch() in a game?


 Not literally, no, but this was quicker to write up in a post
 than to dig up the old assembly and keymaps to paste it all in,
 while still hopefully showing the same basic idea behind it.
 (specifically that it was a simple loop rather than a callback
 or virtual function system like most events nowadays)


Ahh, I see :)


 BTW, this is something I'd use DirectInput for. The Win32 event
 system is about as suitable for game input as the GDI is for game
 graphics.


 All right. If you have the time to write that up too, I'd
 appreciate it. I'll keep it simple now due to my lack of experience
 with it. The one rule though is it needs to remain easy to use. One
 idea here is that newbies can run with it quickly.


Yea. Actually, I think I'll need to take look at Derelict again. I know that 
project already has a lot of these game-appropriate APIs wrapped for D (or 
at least bindings). I don't remember: Did you say this would ideally be 
something for Phobos? If so, I wonder if requiring Derelict would be a 
problem. If it is, then maybe I could just borrow the appropriate code from 
Derelict, depending on the licenses involved (I don't remember what 
Derelict's license is).


 Don't want to join one of the established companies though.


 Oh, hell no. Especially since my preferred style is more NES than
 XBox - I like the simple 2d, low resolution look. I like the
 relatively low frame rate. There's a lot less pressure to code
 it perfectly too (meaning I can just whip stuff out and it's good
 enough as long as its fun).


Yea, same here for the most part. Although I have fallen completely in love 
with the first three Splinter Cell games :) And Pikmin. And Moonbase 
Commander (Although that one's more SNES-style). Actually, there's a fair 
amount in both gaming eras I'm really into (and in-between stuff, like Doom 
1/2/64 and the first two Quakes). But with the newer stuff it just seems to 
be getting harder and harder to find the gems, and even when you do, they're 
likely to have more problems than they used to (Like Sonic Unleashed: The 
daytime levels and puzzle areas were fantastic, but then they had to cram in 
reams of utterly pointless dialog, cutscenes and nighttime levels - and then 
Sonic Colors didn't *remotely* live up to the claims of "It's Sonic 
Unleashed's daytime!" Sonic Team really needs to just step aside and let 
Dimps handle everything...)

And along the NES/SNES lines, I've always been a huge sucker for DOS VGA/EGA 
gaming. Back when Epic put out good games, and Apogee was still relevent 
(and actualy existed). Three hidden gems of that era that I'd highly 
recommend are Capture The Flag (EGA, turn-based strategy), Space Chase (EGA, 
platformer), and God of Thunder (VGA, sort of a slightly linear SNES-Zelda). 
And, of course, almost any of Epic's, Apogee's and id's DOS games. You'd 
probably need DOSBox for all of them these days.



 Apr 06 2011



 next sibling parent  "Nick Sabalausky" <a a.a>  writes:


"Nick Sabalausky" <a a.a> wrote in message 
news:inihjp$hnp$1 digitalmars.com...

 "Adam D. Ruppe" <destructionator gmail.com> wrote in message 
 news:ini1jr$2lj3$1 digitalmars.com...

 Aye, even my homegrown DOS would always write them separately.
 Horrible waste of instructions doing another y << 8 + y << 6 when
 a simple "inc ax" would suffice!


 Yup, exactly. Which reminds me, I've always wanted to actually check to 
 see if modern compilers (or at least DMD) would be smart enough to 
 optimize something like:

 for(i in 128...256)
    arr[i] = ...;

 Into something like:

 auto ptr = arr.ptr + 128;
 auto ptrEnd = arr.ptr + 256;
 for(; ptr < ptrEnd; ptr++)
    *ptr = ...;


Actually, I meant more like this:

enum width = 512;
int x = 10;
for(y in 128...256)
   arr[y * width + x] = ...;

to this:

enum width = 512;
int x = 10;
auto ptr = arr.ptr + 128*width + x;
auto ptrEnd = arr.ptr + 256*width + x;
for(; ptr < ptrEnd; ptr += width)
   *ptr = ...;



 Apr 06 2011



prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com>  writes:


On 07.04.2011 0:11, Nick Sabalausky wrote:

 "Adam D. Ruppe"<destructionator gmail.com>  wrote in message
 news:ini1jr$2lj3$1 digitalmars.com...

 Nick Sabalausky wrote:

 Of course, if you see any fundamental
 problems with this, feel free to let me know :)


 I'm pretty sure your plan would work and would provide a boost,
 but I'm not sure if it's worth the extra time.

 I think the best thing to do will be to partially implement it,
 write a little program with both methods and run some speed tests.
 See if it's still easy to use and how big the difference really is.


 Yea, sounds like a good plan. Although, my design is heavily dependent on

 http://d.puremagic.com/issues/show_bug.cgi?id=5708

 There another similar -inline related bug in there too, but I don't remember
 offhand what it is.


 And even then, things like line drawing, fills and image
 blitting are still better off skipping the
 individual-pixel-access routines


 Aye, even my homegrown DOS would always write them separately.
 Horrible waste of instructions doing another y<<  8 + y<<  6 when
 a simple "inc ax" would suffice!


 Yup, exactly. Which reminds me, I've always wanted to actually check to see
 if modern compilers (or at least DMD) would be smart enough to optimize
 something like:

 for(i in 128...256)
      arr[i] = ...;

 Into something like:

 auto ptr = arr.ptr + 128;
 auto ptrEnd = arr.ptr + 256;
 for(; ptr<  ptrEnd; ptr++)
      *ptr = ...;

 My guess is no (and I'm fairly certain it was "no" back in my DOS days: that
 was the sort of manual optimization I remember doing all the time), but with
 all the improvements that optimizers keep making, I'm not really sure
 anymore.

 Of course, even if the compiler can optimize that, I still doubt it would be
 able to automatically do an equivalent optimization to effectively create,
 for example, Bresenham's algorithm (ie, straight diagonal lines between two
 arbitrary points).


 But anyway, I don't know exactly how you were going about it, but
 the way to do this in OpenGL or DirectX would be to do all your
 drawing to a texture buffer


 I at first just used a SetPixel function in opengl, but when it
 was unacceptable, I simply abandoned the idea of drawing pixels
 to the screen. Instead, I started focusing on polygons and textures -
 a rectangle with a bitmap attached as a texture makes an excellent
 sprite that draws very very quickly, even if rotated or misshapen.

 Once I realized that works so well, pixels weren't important
 anymore so I just stopped using the old functions entirely. They're
 still in the code, still godawfully slow, but I don't care enough
 to change it.


 Yea. I see. I wonder if OpenGL's SetPixel was inlined. If not, I bet we
 could do better (as long as we had direct access to the texture's buffer).


Mmm, am I the only one wondering where did you guys get SetPixel in 
OpenGL ?  It's must have been GDI.
At any rate OpenGL and DirectX is all about sending commands and data 
back and forth between  CPU and videocard (well, there is driver 
involved, doing some translation into specific chip's commands and such).
So no, SetPixel couldn't exactly get inlined just because you can't 
access video ram without jumping through some hoops:  OS -> HAL-> driver 
------->PCI-E or AGP -> ... -> video RAM.  OpenGL and DirectX subsytems 
bypass some of these additional hoops, but still you have to send the 
data down this route. That's why it's usually used for massive 
asynchronous transfers.
E.g. every time you need GetPixel you send "read pixels command" and 
wait utill all the data already streamed in is processed and stored in 
the video RAM, then it reads framebuffer and sends you results 
(effectively stalling all it's processors).
So for "straight" setpixel/putpixel drawing, software render + blit to 
screen is the way
(but I  doubt you need only pixels, and going futher inevitably shows 
why software render sucks).

-- 
Dmitry Olshansky



 Apr 06 2011



 next sibling parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


Dmitry Olshansky wrote:

 Mmm, am I the only one wondering where did you guys get SetPixel in
 OpenGL ?  It's must have been GDI.


Oops, looks like you're right. SetPixel is GDI, and it's pretty
slow too. Looking at my code, I used glBegin(GL_POINTS); glVertex2f
[...] glEnd() as the opengl putpixel. Looks like in an earlier
revision, I also used glDrawPixels at some point, but I didn't keep
it for some reason. Don't remember why (or even what it does.)

But yeah, it's been a while and my brain jumbled it all together...
sorry about that.



 Apr 06 2011



  parent  Dmitry Olshansky <dmitry.olsh gmail.com>  writes:


On 07.04.2011 1:29, Adam D. Ruppe wrote:

 Dmitry Olshansky wrote:

 Mmm, am I the only one wondering where did you guys get SetPixel in
 OpenGL ?  It's must have been GDI.


 Oops, looks like you're right. SetPixel is GDI, and it's pretty
 slow too. Looking at my code, I used glBegin(GL_POINTS); glVertex2f
 [...] glEnd() as the opengl putpixel. Looks like in an earlier
 revision, I also used glDrawPixels at some point, but I didn't keep
 it for some reason. Don't remember why (or even what it does.)

 But yeah, it's been a while and my brain jumbled it all together...
 sorry about that.


Ah,  I see. No problem, and, yes, fro me OpenGL never got drawing single 
pixels this way,
  and still not fast enough even when packed in single array. DrawPixels 
is for drawing block of pixel data (2D images), technically it can draw 
1x1 image.
As for the topic of messing old school DOS-like messing with image, I 
think there was some peculiar MMX-based
code for that buried somewhere in SDL, may be it can be revived in SSE2 
world :)
Long time ago I also sought out simplistic GUI system with direct 
framebuffer, I ended up with design
Windowing System <-> GL <- blit -> software renderer should be easily 
portable as far as the wrapper around windowing system is minimalistic 
(e.g. map repaint, keys and mouse events).

-- 
Dmitry Olshansky



 Apr 06 2011



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"Dmitry Olshansky" <dmitry.olsh gmail.com> wrote in message 
news:inik5u$n13$1 digitalmars.com...

 Mmm, am I the only one wondering where did you guys get SetPixel in OpenGL 
 ?  It's must have been GDI.
 At any rate OpenGL and DirectX is all about sending commands and data back 
 and forth between  CPU and videocard (well, there is driver involved, 
 doing some translation into specific chip's commands and such).
 So no, SetPixel couldn't exactly get inlined just because you can't access 
 video ram without jumping through some hoops:  OS -> HAL-> 
 driver ------->PCI-E or AGP -> ... -> video RAM.  OpenGL and DirectX 
 subsytems bypass some of these additional hoops, but still you have to 
 send the data down this route. That's why it's usually used for massive 
 asynchronous transfers.
 E.g. every time you need GetPixel you send "read pixels command" and wait 
 utill all the data already streamed in is processed and stored in the 
 video RAM, then it reads framebuffer and sends you results (effectively 
 stalling all it's processors).
 So for "straight" setpixel/putpixel drawing, software render + blit to 
 screen is the way
 (but I  doubt you need only pixels, and going futher inevitably shows why 
 software render sucks).


What I was thinking of was using some set/get pixel stuff to draw to 
system-ram and then use OpenGL/DirectX to transfer it to video-ram when done 
(I have no idea which way Adam was doing it).

And yea, you're right that software rendering sucks performance-wise. But 
the main orginal point was t have a way to just toy around with image 
drawing in an easy classic DOS-style. From there, my thoughts were "ok, how 
to make this approach as close to being efficient as it can realistically 
get?"



 Apr 06 2011



  parent  Kagamin <spam here.lot>  writes:


Nick Sabalausky Wrote:


 And yea, you're right that software rendering sucks performance-wise. But 
 the main orginal point was t have a way to just toy around with image 
 drawing in an easy classic DOS-style. From there, my thoughts were "ok, how 
 to make this approach as close to being efficient as it can realistically 
 get?"


There was a c++ drawing library proposed to be ported to D, which does what you
talk about.



 Apr 07 2011



prev sibling  parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


I'm snipping a bit since we're on the same page.

Nick Sabalausky wrote:

 Yea. I see. I wonder if OpenGL's SetPixel was inlined.


Note my mistake: SetPixel is GDI. I got it mixed up in my brain.


  Did you say this would ideally be something for Phobos?


Yes, I hope so. It'll be nice for D if newbies can dive right into
this stuff out of the box.


 And along the NES/SNES lines, I've always been a huge sucker for
 DOS VGA/EGA gaming.


Another great thing was all you could do with the text mode, like
Walter's Empire DOS version.

That oem character set with the 80x25 cell display, 16 color
palette.. and, of course, the blink bit could go incredibly far
in making a nice little game board.


 You'd probably need DOSBox for all of them these days.


DOS programs are one reason why I was so reluctant to get into the
64 bit bandwagon. I eventually caved in a few months ago when
my old motherboard gave up the magic smoke, but I really didn't
want to lose native 16 bit ability!

DOSBox does the job, but I've always found it hard to use compared
to the "real" thing.



 Apr 06 2011



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:inimg1$t0m$1 digitalmars.com...

 Nick Sabalausky wrote:

 And along the NES/SNES lines, I've always been a huge sucker for
 DOS VGA/EGA gaming.


 Another great thing was all you could do with the text mode, like
 Walter's Empire DOS version.


I admit I've never actually played any version of Empire. But then I've 
never really been particularly into resource-management strategies (I 
*think* that's what Empire is...something similar to Civilazation, right?)



 That oem character set with the 80x25 cell display, 16 color
 palette.. and, of course, the blink bit could go incredibly far
 in making a nice little game board.


Yea. Kroz and ZZT were great. And I made a few little text-mode games in 
QBASIC a lifetime ago (And posted them on AOL, way back at AOL v1.x :) 
Pre-web, heh). Still have those QBASIC games around here somewhere. The 
characters for the extended-ASCII range and control codes were really useful 
(the walls, the two "face" characters, etc). I totally forgot about the 
blink bit!



 You'd probably need DOSBox for all of them these days.


 DOS programs are one reason why I was so reluctant to get into the
 64 bit bandwagon. I eventually caved in a few months ago when
 my old motherboard gave up the magic smoke, but I really didn't
 want to lose native 16 bit ability!

 DOSBox does the job, but I've always found it hard to use compared
 to the "real" thing.


I had no idea the 64-bit chips couldn't do 16-bit!

I'm actually not real concerned about that though. I've found that a *lot* 
of the old DOS stuff I like is entirely broken on my modern(-ish) 32-bit XP 
system (and a lot of it never played well with Windows in the first place), 
so I usually have to use either DOXBox or my old 486 anyway. Not that DOSBox 
is perfect yet, unfortunately, but it seems to actually have much better 
compatibility than trying to run things "natively".



 Apr 06 2011



  parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


Nick Sabalausky wrote:

 I admit I've never actually played any version of Empire. But then
 I've never really been particularly into resource-management
 strategies (I *think* that's what Empire is...something similar to
 Civilazation, right?)


I've never played Civilization! But, I wouldn't call it resource
management really. Every turn, you can make more units (more
or less depending on how many cities you've captured), and while
that's an important part of the game, I'd say more of it is
positioning your guys and advancing without leaving your own cities
open to be conquered.

Resource management makes me think of something like Warcraft
where controlling the gold mines is more important than army
positioning. Holding cities is vital to victory in Empire, but
positioning your army is at least as important too.


 I had no idea the 64-bit chips couldn't do 16-bit!


Then can, but not when they are in 64 bit mode.

In 32 bit mode, it's the same as the old chips. You can run 32 bit
code and 16 bit code side by side, but no 64 bit.

In 64 bit mode, you can now run 64 and 32 bit code together, but
no 16 bit.

The mode it runs in depends on your operating system. Put a 32 bit
OS on the 64 bit chip and everything works the same as the old
processors. But, if you want to actually use the new capabilities,
you've gotta go with a 64 bit OS, which means losing native 16 bit
(at least until you reboot into 32 or 16 bit OS)



 Apr 06 2011



 next sibling parent  Daniel Gibson <metalcaedes gmail.com>  writes:


Am 07.04.2011 00:33, schrieb Adam D. Ruppe:

 Nick Sabalausky wrote:

 I admit I've never actually played any version of Empire. But then
 I've never really been particularly into resource-management
 strategies (I *think* that's what Empire is...something similar to
 Civilazation, right?)


 
 I've never played Civilization! But, I wouldn't call it resource
 management really. Every turn, you can make more units (more
 or less depending on how many cities you've captured), and while
 that's an important part of the game, I'd say more of it is
 positioning your guys and advancing without leaving your own cities
 open to be conquered.
 
 Resource management makes me think of something like Warcraft
 where controlling the gold mines is more important than army
 positioning. Holding cities is vital to victory in Empire, but
 positioning your army is at least as important too.
 

 I had no idea the 64-bit chips couldn't do 16-bit!


 
 Then can, but not when they are in 64 bit mode.
 
 In 32 bit mode, it's the same as the old chips. You can run 32 bit
 code and 16 bit code side by side, but no 64 bit.
 
 In 64 bit mode, you can now run 64 and 32 bit code together, but
 no 16 bit.
 
 The mode it runs in depends on your operating system. Put a 32 bit
 OS on the 64 bit chip and everything works the same as the old
 processors. But, if you want to actually use the new capabilities,
 you've gotta go with a 64 bit OS, which means losing native 16 bit
 (at least until you reboot into 32 or 16 bit OS)


You can probably just run a 32bit VM with DOS (or Win9x or something) in
it (via VirtualBox or similar).
Maybe in some cases this runs better than DosBox (Or at least as good as
a native 32bit Windows).

Cheers,
- Daniel



 Apr 06 2011



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:inipn4$14rq$1 digitalmars.com...

 Nick Sabalausky wrote:

 I admit I've never actually played any version of Empire. But then
 I've never really been particularly into resource-management
 strategies (I *think* that's what Empire is...something similar to
 Civilazation, right?)


 I've never played Civilization! But, I wouldn't call it resource
 management really. Every turn, you can make more units (more
 or less depending on how many cities you've captured), and while
 that's an important part of the game, I'd say more of it is
 positioning your guys and advancing without leaving your own cities
 open to be conquered.

 Resource management makes me think of something like Warcraft
 where controlling the gold mines is more important than army
 positioning. Holding cities is vital to victory in Empire, but
 positioning your army is at least as important too.


Ah, so it's really more a straight strategy game, maybe with a slight 
tactical leaning. Maybe I should give it a try sometime then. Is it 
turn-based or realtime? I'm usually more a turn-based fan, although Pikmin 
was a damn good realtime strategy.



 Apr 06 2011



  parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


Nick Sabalausky wrote:

 Is [Empire] turn-based or realtime?


Turn based.

Here's the site: http://www.classicempire.com/

I like the old version - the text mode graphics are nice.

Don't blame me if it gets you fired and divorced :) Easy to lose
track of time once you get into it!



 Apr 06 2011



  parent  "Nick Sabalausky" <a a.a>  writes:


"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:inj0g1$1hgr$1 digitalmars.com...

 Nick Sabalausky wrote:

 Is [Empire] turn-based or realtime?


 Turn based.

 Here's the site: http://www.classicempire.com/

 I like the old version - the text mode graphics are nice.

 Don't blame me if it gets you fired and divorced :) Easy to lose
 track of time once you get into it!


The text mode version seem to just run by itself (really, really fast). The 
other one works for me. Still learning it, but seems pretty cool so far.



 Apr 06 2011



prev sibling  parent reply Michel Fortin <michel.fortin michelf.com>  writes:


On 2011-04-05 23:07:33 -0400, Adam D. Ruppe <destructionator gmail.com> said:


 Note: I just updated my simpledisplay.d. My color constructor
 said b = c when I meant this.b = c... hence everything was yellow!
 You can download again from the same place.


I played with it yesterday and never found why the blue channel didn't work!

By the way it works well with X11 on Mac OS X (if I change the "version 
(linux)" to "version (OSX)").

I also made a working OS X implementation (Cocoa).



 Nick Sabalausky wrote:

 I haven't benchmarked or even tested this, and heck, maybe I'm just
 a dinosaur, but for better speed and flexibility I'd recommend
 something more like what I've attached.


 
 Yea, that does sound better. Though I have a few comments...
 

 The width is statically-known, so the compiler can optimize the
 index calculation from multiplication to shifts when appropriate.


 
 One concern I have here is will it be an incompatible type with
 dynamic widths? i.e. an image loaded from a file? (I'll be hopefully
 cleaning up my png and bmp loaders in the near future to use with
 this.)


I don't think having fixed-size image will be a useful optimization, 
except perhaps if you manipulate a lot of tiny images of the same size.



 Maybe it could use an interface to smooth that over.
 
 I actually had a similar fight with myself over Indexed vs TrueColor
 when writing the original thing. They really don't have compatible
 interfaces. Sure, you could do some kind of putpixel(uint data)
 for each of them, but it's not really the same.
 
 So I think they should be separate types, with functions to convert
 back and forth. (both conversions being lossy in their own way..
 just because two palette entries have the same rgb values doesn't
 mean the two colors are semantically the same.)


Don't forget that there's actually much more colorspaces than indexed 
and RGB. There's RGBA (when you need semi-transparency), there's CYMB 
(for print), there's grayscale. And in some cases HSV or XYZ could be 
useful too. And for each of these someone might want different bit 
depth. Can't we make things flexible enough for that by using a 
template?

	final class Bitmap(Color) : Image {
		void opIndexAssign(int x, int y, Color color) {
			pixels[y * width + x] = Color(color);
		}

		size_t width, height;
		Color[] pixels;
	}

This way, you can have a bitmap of RGBColor, or RGBAColor (with an 
alpha mask), GrayColor, IndexedColor, or whatever color type you can 
come with, and algorithms can be reused.



 Wow, I'm off topic again. Anyway, for the event loop here, I'm
 thinking something similar to how std.concurrency does it might
 be a good approach: a bunch of delegates, matched to events by
 their signature. Simple signatures could be accepted as well
 as fancier ones.
 
 // need to make a simple window separately here so it is persistent
 auto win = new DrawableWindow(width, height);
 
 // still use an image the same way. Alternatively, DrawableWindow
 // could implement the same interface as Image, probably double
 // buffering internally anyway, so pretty much same implementation.
 auto image = new Image(width, height);
 
 window.eventLoop(
    50, // first parameter is the timeout. can be 0 to only react
        // to events, but putting one in gives you an easy to use
        // frame pulse for drawing
    (int keyPressed) { // might be a struct KeyEvent rather than int
         // react to the key
    },
    (int x, int y, int mouseButton) {
         // react to a mouse click
    },
    () { // no params means your timeout happened, time to draw
         // draw your frame...
 
         image.display(win); // this overload uses the existing
                             // window and returns immediately
                             // rather than making and waiting
    }
    // might also offer a platform specific msg, wParam, lParam
    // so you could in theory do all of Win32 based on this same
    // framework
 );


Overall, I really like this concept. I'd like it better if 
image.display(win) was replaced with "window.image = image" however.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/



 Apr 06 2011



 next sibling parent reply Matthias Pleh <jens konrad.net>  writes:


Am 06.04.2011 14:49, schrieb Michel Fortin:

      final class Bitmap(Color) : Image {
          void opIndexAssign(int x, int y, Color color) {
              pixels[y * width + x] = Color(color);
          }

          size_t width, height;
          Color[] pixels;
      }



Yep, exactly. I would implement it as template.

About the render backend, Nick mentioned.
In the first step, I would just draw all objects (lines, boxes, circles) 
to the buffer and then render it as image per gdi/xlib.

this render should ideally be in a single file, so other backends can be 
implemented (gdi/direct2d/cairo/xcb/cocoa/..)


°Matthias



 Apr 06 2011



  parent reply Michel Fortin <michel.fortin michelf.com>  writes:


On 2011-04-06 10:25:42 -0400, Matthias Pleh <jens konrad.net> said:


 Am 06.04.2011 14:49, schrieb Michel Fortin:

      final class Bitmap(Color) : Image {
          void opIndexAssign(int x, int y, Color color) {
              pixels[y * width + x] = Color(color);
          }
 
          size_t width, height;
          Color[] pixels;
      }


 
 Yep, exactly. I would implement it as template.
 
 About the render backend, Nick mentioned.
 In the first step, I would just draw all objects (lines, boxes, 
 circles) to the buffer and then render it as image per gdi/xlib.
 
 this render should ideally be in a single file, so other backends can 
 be implemented (gdi/direct2d/cairo/xcb/cocoa/..)


Since you're at it, have you considered making the API flexible enough 
so it could support vector images too?

	// return an object derived from image depending on the actual file type
	Image im = loadImage("filename");

	// creating a bitmap for on-screen rendering
	auto bitmap = new Bitmap!RGBColor(im.width, im.height);

	// base image class has a virtual function to draw itself on a bitmap at
	// a given location, so it's easy to draw it on screen
	im.draw(10, 10, bitmap);

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/



 Apr 06 2011



  parent  Matthias Pleh <jens konrad.net>  writes:


Am 06.04.2011 17:35, schrieb Michel Fortin:

 On 2011-04-06 10:25:42 -0400, Matthias Pleh <jens konrad.net> said:


 Am 06.04.2011 14:49, schrieb Michel Fortin:

 final class Bitmap(Color) : Image {
 void opIndexAssign(int x, int y, Color color) {
 pixels[y * width + x] = Color(color);
 }

 size_t width, height;
 Color[] pixels;
 }


 Yep, exactly. I would implement it as template.

 About the render backend, Nick mentioned.
 In the first step, I would just draw all objects (lines, boxes,
 circles) to the buffer and then render it as image per gdi/xlib.

 this render should ideally be in a single file, so other backends can
 be implemented (gdi/direct2d/cairo/xcb/cocoa/..)


 Since you're at it, have you considered making the API flexible enough
 so it could support vector images too?

 // return an object derived from image depending on the actual file type
 Image im = loadImage("filename");

 // creating a bitmap for on-screen rendering
 auto bitmap = new Bitmap!RGBColor(im.width, im.height);

 // base image class has a virtual function to draw itself on a bitmap at
 // a given location, so it's easy to draw it on screen
 im.draw(10, 10, bitmap);



Yep, definitley this would be an issue to place on the todo-list.
But let's just start with a basic implementation with simple raster 
graphics, but always in mind to extand it in the future.
BTW: to implement the whole SVG specification, that would be a huge 
project, but basic vector drawings would be definitive a nice thing to have.

°Matthias



 Apr 06 2011



prev sibling next sibling parent  Adam D. Ruppe <destructionator gmail.com>  writes:


Michel Fortin wrote:

 I played with it yesterday and never found why the blue channel
 didn't work!


Yeah, I noticed that too after posting it. Here's the problem:

this(int a, int b, int c) {
    r = cast(ubyte) a;
    g = cast(ubyte) b;
    b = cast(ubyte) c;
}

Those quick one letter variable names in a barely necessary
constructor ended up shadowing each other - that last line
wrote to the local parameter instead of to the struct member
like I meant...

Stupid me. Make it this.b = ... and it works.



 I also made a working OS X implementation (Cocoa).


Cool!


 Can't we make things flexible enough for [different colorspaces]
 by using a template?


Yeah, probably.


 I'd like it better if image.display(win) was replaced with
 "window.image = image" however.


Hmm, maybe. I'm thinking image.display(win) could be some kind of
rendering function that then calls out to bitblt or whatever to
draw in any location though, offering some flexibility that the
property wouldn't provide.

So it's more like image.drawAt(drawable_surface, x, y);

Where the drawable_surface could be a window or another image, and
the image renders itself to that destination. Default parameters
would tell it to assume upper left of a new window, keeping the
simple display() call just working.



 Apr 06 2011



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:inhnnn$236n$1 digitalmars.com...

 Nick Sabalausky wrote:

 I haven't benchmarked or even tested this, and heck, maybe I'm just
 a dinosaur, but for better speed and flexibility I'd recommend
 something more like what I've attached.


 Yea, that does sound better. Though I have a few comments...


 The width is statically-known, so the compiler can optimize the
 index calculation from multiplication to shifts when appropriate.


 One concern I have here is will it be an incompatible type with
 dynamic widths? i.e. an image loaded from a file? (I'll be hopefully
 cleaning up my png and bmp loaders in the near future to use with
 this.)


 I don't think having fixed-size image will be a useful optimization, 
 except perhaps if you manipulate a lot of tiny images of the same size.


Manipulating images in software involves accessing a *lot* of pixels, so you 
have a very big "inner loop" situation. If the width isn't statically-known, 
then:

- Every arbitrary pixel access requires a multiply (instead of a shift or 
sum-of-shifts like you can do if the width is statically-known and a power 
of 2 or a sum of powers of 2).

- Every sequential non-horizontal pixel access requires an extra register to 
be used (to hold the pointer-increment value).

Over all the pixels in a scene, that can really add up. In fact, that's one 
of the reasons game engines traditionally have only supported very specific 
finite sets of fixed image sizes.

Of course, usually you'd avoid doing direct pixel access and use 
specially-optimized higher-level primitives instead (although even those can 
often benefit from a statically-known power-of-2 width). But since one of 
the goals behind this API is to be used as a "playground", we can expect 
that people are going to want to be doing a lot of direct pixel access.

Although, we'll certainly want to do some benchmarking to really know for 
sure.


 Don't forget that there's actually much more colorspaces than indexed and 
 RGB. There's RGBA (when you need semi-transparency), there's CYMB (for 
 print), there's grayscale. And in some cases HSV or XYZ could be useful 
 too. And for each of these someone might want different bit depth. Can't 
 we make things flexible enough for that by using a template?

 final class Bitmap(Color) : Image {
 void opIndexAssign(int x, int y, Color color) {
 pixels[y * width + x] = Color(color);
 }

 size_t width, height;
 Color[] pixels;
 }

 This way, you can have a bitmap of RGBColor, or RGBAColor (with an alpha 
 mask), GrayColor, IndexedColor, or whatever color type you can come with, 
 and algorithms can be reused.


Yea, that's probably a very good idea.



 Apr 06 2011



  parent reply David Nadlinger <see klickverbot.at>  writes:


On 4/6/11 10:41 PM, Nick Sabalausky wrote:

 I don't think having fixed-size image will be a useful optimization,
 except perhaps if you manipulate a lot of tiny images of the same size.


 Manipulating images in software involves accessing a *lot* of pixels, so you
 have a very big "inner loop" situation. If the width isn't statically-known,
 then:[â€Ĥ]


If you want to write something generic that actually performs well, the 
Adobe/Boost ÂğGeneric Image LibraryÂĞ might be an interesting example: 
www.boost.org/doc/libs/release/libs/gil/doc/index.html

David



 Apr 06 2011



 next sibling parent  Matthias Pleh <jens konrad.net>  writes:


Am 06.04.2011 22:50, schrieb David Nadlinger:

 On 4/6/11 10:41 PM, Nick Sabalausky wrote:

 I don't think having fixed-size image will be a useful optimization,
 except perhaps if you manipulate a lot of tiny images of the same size.


 Manipulating images in software involves accessing a *lot* of pixels,
 so you
 have a very big "inner loop" situation. If the width isn't
 statically-known,
 then:[â€Ĥ]


 If you want to write something generic that actually performs well, the
 Adobe/Boost ÂğGeneric Image LibraryÂĞ might be an interesting example:
 www.boost.org/doc/libs/release/libs/gil/doc/index.html

 David



Thank's for sharing. Seems to be a cool project.
I will have a look at it.

°Matthias



 Apr 06 2011



prev sibling  parent  "Nick Sabalausky" <a a.a>  writes:


"David Nadlinger" <see klickverbot.at> wrote in message 
news:inijsn$m9r$1 digitalmars.com...

 On 4/6/11 10:41 PM, Nick Sabalausky wrote:

 I don't think having fixed-size image will be a useful optimization,
 except perhaps if you manipulate a lot of tiny images of the same size.


 Manipulating images in software involves accessing a *lot* of pixels, so 
 you
 have a very big "inner loop" situation. If the width isn't 
 statically-known,
 then:[.]


 If you want to write something generic that actually performs well, the 
 Adobe/Boost ğGeneric Image LibraryĞ might be an interesting example: 
 www.boost.org/doc/libs/release/libs/gil/doc/index.html


Just took a brief glance. Does seem potentially interesting. Appears to 
essentially be a C++ std.range/std.algorithm for images. I can imagine a 
similar approach might be fruitful for us.



 Apr 06 2011



prev sibling next sibling parent reply spir <denis.spir gmail.com>  writes:


On 04/05/2011 01:41 AM, Michel Fortin wrote:

 On 2011-04-04 17:27:05 -0400, Matthias Pleh <jens konrad.net> said:


 I would like to fill this gap and create a really good D GUI library

 Any thoughts, comments ... ?


 Just an observation...

 Cross platform libraries are fine, but they generally aren't very great either.
 They'll always stretch in one way or another the standard way to do things when
 put on a given platform. The end result will almost always look substandard
 when using that library in the environment it was not primarily designed for.

 On the other hand, one thing that is missing right now, in D and in most
 languages, is a standard way to display graphics. By that I mean if we had in
 Phobos a module that could just open a window and let you draw things in it,
 it'd make learning programming much more fun and it'd be useful for rapid
 prototyping of anything that involves graphics. It doesn't need to be
 complicated -- it doesn't even need to have a GUI -- just drawing things and
 viewing them somewhere on a screen would be great. Later on you can add click
 support, full screen mode and other features if deemed useful, but the goal
 would never be provide bindings for every piece of GUI on all platforms.

 So my observation is that a cross platform full-featured GUI will always fail
 somewhere (mostly where those platforms differs) whereas a cross platform
 drawing module with display capabilities is much more universally useful, is
 more easily approachable, and is much less code to maintain.


I would love that! Actually was thinking at something like that yesterday.

An ideal design (for me) for this kind of exploratory / fun programming would 
be having
* a drawing frame using most of the screen
* a minimal terminal frame down there (like in prog editors)
* a 'control' frame on the left
The control part beeing firstly for feedback on what happens in the drawing 
part. Eg display range, min/max, average... when drawing a function's curve.
Then, all kinds of sophiscation (control allows input, mouse, whatever...) can 
be added.

Unfortunately, I really have no idea on how to do that; else, I would have 
developped it already. But I would definitely help, if possible, anyone who 
knows and wants to invest time on such a project.

My uses for this would be similar to Michel's "make learning programming much 
more fun and it'd be useful for rapid prototyping". Especially around toy games 
/ aspects of games / samples. Having no visualisation (read: the model w/o the 
view) is deeply frustrating and makes everything abstract (read: far harder).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com



 Apr 04 2011



  parent reply Michel Fortin <michel.fortin michelf.com>  writes:


On 2011-04-04 20:45:49 -0400, spir <denis.spir gmail.com> said:


 I would love that! Actually was thinking at something like that yesterday.
 
 An ideal design (for me) for this kind of exploratory / fun programming 
 would be having
 * a drawing frame using most of the screen
 * a minimal terminal frame down there (like in prog editors)
 * a 'control' frame on the left
 The control part beeing firstly for feedback on what happens in the 
 drawing part. Eg display range, min/max, average... when drawing a 
 function's curve.
 Then, all kinds of sophiscation (control allows input, mouse, 
 whatever...) can be added.


Actually, I think it needs to stay simple: provide a drawing area in a 
window and let the program draw whatever he wants. I'd leave controls 
and other GUI stuff to actual GUI frameworks (at least in a first 
incarnation).



 Unfortunately, I really have no idea on how to do that; else, I would 
 have developped it already. But I would definitely help, if possible, 
 anyone who knows and wants to invest time on such a project.


The first thing needed is an API. Ideally, the API would have the 
concept of an image buffer, some primitives to draw in the buffer, and 
a way to put the buffer on screen (typically in a window) or elsewhere 
(in a PNG file for instance).

It would also be nice to be able to load an image from a file, but 
that's a little more complicated.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/



 Apr 04 2011



  parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


Michel Fortin wrote:

 It would also be nice to be able to load an image from a file, but
 that's a little more complicated.


I have some .bmp and .png loading written up too. Doesn't implement
every feature of either format, but enough to get by.

From my program:

import arsd.bmp;
void main() {
       auto i = new BMP("lol.bmp"); // loading from file

       i.display(); // display it to the screen
}

Alternatively, make one with arrays:

void main() {
     auto i = new Image(255, 255);
     for(int b = 0; b < h; b++)
     for(int a = 0; a < w; a++)
	i.setPixel(a,b,Color(255,a,0)); // truecolor

     i.display();
}



You can also write out to a file or to a memory array (should
probably be some kind of lazy range). When combined with cgi.d,
that means you can output images to the web browser like so:

http://arsdnet.net/cgi-bin/gradient?h=100&w=100&c1=ff0000&c2=00ff00

No need for external libraries - my png read/write is homegrown in
D. (which is why it doesn't implement the full standard, but it's
also much smaller and simpler to use than something that does)


It doesn't offer much for drawing - it's just a memory array
and a few of my ancient DOS routines ported over, but it's a start.

I'll see about cleaning it up for a release next chance I get.



 Apr 04 2011



  parent reply spir <denis.spir gmail.com>  writes:


On 04/05/2011 06:13 AM, Adam D. Ruppe wrote:

 Michel Fortin wrote:

 It would also be nice to be able to load an image from a file, but
 that's a little more complicated.


 I have some .bmp and .png loading written up too. Doesn't implement
 every feature of either format, but enough to get by.

  From my program:

 import arsd.bmp;
 void main() {
         auto i = new BMP("lol.bmp"); // loading from file

         i.display(); // display it to the screen
 }

 Alternatively, make one with arrays:

 void main() {
       auto i = new Image(255, 255);
       for(int b = 0; b<  h; b++)
       for(int a = 0; a<  w; a++)
 	i.setPixel(a,b,Color(255,a,0)); // truecolor

       i.display();
 }



 You can also write out to a file or to a memory array (should
 probably be some kind of lazy range). When combined with cgi.d,
 that means you can output images to the web browser like so:

 http://arsdnet.net/cgi-bin/gradient?h=100&w=100&c1=ff0000&c2=00ff00

 No need for external libraries - my png read/write is homegrown in
 D. (which is why it doesn't implement the full standard, but it's
 also much smaller and simpler to use than something that does)


 It doesn't offer much for drawing - it's just a memory array
 and a few of my ancient DOS routines ported over, but it's a start.

 I'll see about cleaning it up for a release next chance I get.


What about having just one image type (pixmap) and allowing its initialisation 
from files of various formats:
     auto i = new Image(BMP, "lol.bmp");
?

Denis
-- 
_________________
vita es estrany
spir.wikidot.com



 Apr 05 2011



  parent  Adam D. Ruppe <destructionator gmail.com>  writes:


spir wrote:

 What about having just one image type (pixmap) and allowing its
 initialisation from files of various formats:


Yeah, that's essentially how it works. They use the same Image
class underneath.

The differences between bmp and png are among the things I want
to clean up for release though. It's not pretty like it should be
right now.



 Apr 05 2011



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2011-04-05 01:41, Michel Fortin wrote:

 On 2011-04-04 17:27:05 -0400, Matthias Pleh <jens konrad.net> said:


 I would like to fill this gap and create a really good D GUI library

 Any thoughts, comments ... ?


 Just an observation...

 Cross platform libraries are fine, but they generally aren't very great
 either. They'll always stretch in one way or another the standard way to
 do things when put on a given platform. The end result will almost
 always look substandard when using that library in the environment it
 was not primarily designed for.


If you use the cross platform library for most of the application and 
then use the native libraries to add details and further customize the 
application I think it can look pretty good.


 On the other hand, one thing that is missing right now, in D and in most
 languages, is a standard way to display graphics. By that I mean if we
 had in Phobos a module that could just open a window and let you draw
 things in it, it'd make learning programming much more fun and it'd be
 useful for rapid prototyping of anything that involves graphics. It
 doesn't need to be complicated -- it doesn't even need to have a GUI --
 just drawing things and viewing them somewhere on a screen would be
 great. Later on you can add click support, full screen mode and other
 features if deemed useful, but the goal would never be provide bindings
 for every piece of GUI on all platforms.

 So my observation is that a cross platform full-featured GUI will always
 fail somewhere (mostly where those platforms differs) whereas a cross
 platform drawing module with display capabilities is much more
 universally useful, is more easily approachable, and is much less code
 to maintain.



-- 
/Jacob Carlborg



 Apr 05 2011



prev sibling next sibling parent reply Kagamin <spam here.lot>  writes:


Matthias Pleh Wrote:


 This were the requirments for the GUI library:
 - Corss-platform (Win/linux)
 - not just a port, but adjusted to the language
 - mostly written in this language, so you can easy debug the lib,
    this means no wrapper library, just system libraries
    (Though gtk+ on linux would hold as a system library so GtkD for 
 linux would be OK, but not on Windows!
 - obviously suitable license for a commercial product
 
 Unfortunately All known GUI-libraries for D fails on this requirments
 So the choice has fallen to C++/Qt


Qt doesn't fulfill the requirement for "just system libraries".



 Apr 04 2011



  parent reply Matthias Pleh <jens konrad.net>  writes:


Am 05.04.2011 08:20, schrieb Kagamin:

 Matthias Pleh Wrote:


 This were the requirments for the GUI library:
 - Corss-platform (Win/linux)
 - not just a port, but adjusted to the language
 - mostly written in this language, so you can easy debug the lib,
     this means no wrapper library, just system libraries
     (Though gtk+ on linux would hold as a system library so GtkD for
 linux would be OK, but not on Windows!
 - obviously suitable license for a commercial product

 Unfortunately All known GUI-libraries for D fails on this requirments
 So the choice has fallen to C++/Qt


 Qt doesn't fulfill the requirement for "just system libraries".


<quote>
This were the requirments for the GUI library:
</quote>

Qt is here not the requirement, but rather the GUI library itself



 Apr 05 2011



  parent  Kagamin <spam here.lot>  writes:


Matthias Pleh Wrote:


 Am 05.04.2011 08:20, schrieb Kagamin:

 Matthias Pleh Wrote:


 This were the requirments for the GUI library:
 - Corss-platform (Win/linux)
 - not just a port, but adjusted to the language
 - mostly written in this language, so you can easy debug the lib,
     this means no wrapper library, just system libraries
     (Though gtk+ on linux would hold as a system library so GtkD for
 linux would be OK, but not on Windows!
 - obviously suitable license for a commercial product

 Unfortunately All known GUI-libraries for D fails on this requirments
 So the choice has fallen to C++/Qt


 Qt doesn't fulfill the requirement for "just system libraries".


 
 <quote>
 This were the requirments for the GUI library:
 </quote>
 
 Qt is here not the requirement, but rather the GUI library itself


I mean, Qt fails on these requirements just like any other GUI library.



 Apr 05 2011



prev sibling next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-04-04 23:27, Matthias Pleh wrote:

 was: [GSoC] Container proposals by Ishan and Christian

 To preventing losing this thread, I have created a new one ...
 Additional, I've added a license column on the GuiLibraries-table on the
 wiki.

 So, let me summarize my thoughts, why I think a good Gui library is
 important for the D community.
 I'm working for an enginge builder company. Our product is mainly
 mechanical, but also has a software part, which is created and
 maintained by a 16 (and growing) man team. Our softwareproduct is mainly
 server-side and timecritical, written in C++/MFC and very old. We've
 decided to create it new from scratch. As a member of the design team of
 this new project I've tried to inturoduce D for this. But it was
 impossible to assure the others. The main counter-argument was the lack
 of a good D-Gui library, though the main part is serverside, but the
 client-side GUI have to be written in the same language.

 This were the requirments for the GUI library:
 - Corss-platform (Win/linux)
 - not just a port, but adjusted to the language
 - mostly written in this language, so you can easy debug the lib,
 this means no wrapper library, just system libraries
 (Though gtk+ on linux would hold as a system library so GtkD for linux
 would be OK, but not on Windows!
 - obviously suitable license for a commercial product

 Unfortunately All known GUI-libraries for D fails on this requirments
 So the choice has fallen to C++/Qt


Why is C++/Qt good enough but not D/Qt ?


 I would like to fill this gap and create a really good D GUI library

 Any thoughts, comments ... ?


 °Matthias



-- 
/Jacob Carlborg



 Apr 05 2011



  parent reply Matthias Pleh <jens konrad.net>  writes:


Am 05.04.2011 10:43, schrieb Jacob Carlborg:

 Why is C++/Qt good enough but not D/Qt ?


As I mentioned before, I could live with such a solution.
When we decided our strategy one year ago, QtD was far away from ready 
but gtkD was already usable and stable. I was the one how recommend the 
use of D/gtkD. But there exist developers and manager, who _don't_ want 
an ecosystem with different languages. (That's not my opinion, but the 
meaning of our lead developer and our managers)
So this means:
- D solution:
	gtkD   -> D
	gtk+   -> c
	phobos -> D
	perhabs other libraries needed?
- C++ solution:
	Qt	-> C++
	STL	-> C++
       optional:
	Boost   -> C++


This is also the reason why so many developers like VisualStudio and 
.Net! You install it and you have everything needed from one hand.
- IDE

the winapi which is a system library)

Ok, I know, these peoples also are the one who don't know the power of a 
really good OS like linux.
In Ubuntu I just type:
$ sudo apt-get install qtcreator
and I have also everything installed I need for development.
But this is not the case on windows. Windows user thinks different.

So this discussion is really the same as Windows vs. linux.
There is always someone who persist on windows, regarless how good other 
systems are!

So I think for short or middle term such solution like gtkD, QtD, DWT 
are good, but for the long term the D community needs a D GUI library 
completly written in D.

Just my thoughts
°Matthias



 Apr 05 2011



 next sibling parent  Jacob Carlborg <doob me.com>  writes:


On 2011-04-05 13:08, Matthias Pleh wrote:

 Am 05.04.2011 10:43, schrieb Jacob Carlborg:

 Why is C++/Qt good enough but not D/Qt ?


 As I mentioned before, I could live with such a solution.
 When we decided our strategy one year ago, QtD was far away from ready
 but gtkD was already usable and stable. I was the one how recommend the
 use of D/gtkD. But there exist developers and manager, who _don't_ want
 an ecosystem with different languages. (That's not my opinion, but the
 meaning of our lead developer and our managers)
 So this means:
 - D solution:
 gtkD -> D
 gtk+ -> c
 phobos -> D
 perhabs other libraries needed?
 - C++ solution:
 Qt -> C++
 STL -> C++
 optional:
 Boost -> C++


 This is also the reason why so many developers like VisualStudio and
 .Net! You install it and you have everything needed from one hand.
 - IDE

 the winapi which is a system library)

 Ok, I know, these peoples also are the one who don't know the power of a
 really good OS like linux.
 In Ubuntu I just type:
 $ sudo apt-get install qtcreator
 and I have also everything installed I need for development.
 But this is not the case on windows. Windows user thinks different.

 So this discussion is really the same as Windows vs. linux.
 There is always someone who persist on windows, regarless how good other
 systems are!

 So I think for short or middle term such solution like gtkD, QtD, DWT
 are good, but for the long term the D community needs a D GUI library
 completly written in D.

 Just my thoughts
 °Matthias


Ok, I see.

-- 
/Jacob Carlborg



 Apr 05 2011



prev sibling  parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-04-05 13:08, Matthias Pleh wrote:

 So I think for short or middle term such solution like gtkD, QtD, DWT
 are good, but for the long term the D community needs a D GUI library
 completly written in D.

 Just my thoughts
 °Matthias


You do know that DWT is completely written in D? Don't you think we can 
create an environment for creating D GUI applications using DWT?

-- 
/Jacob Carlborg



 Apr 05 2011



 next sibling parent reply Matthias Pleh <jens konrad.net>  writes:


Am 05.04.2011 15:06, schrieb Jacob Carlborg:

 On 2011-04-05 13:08, Matthias Pleh wrote:

 So I think for short or middle term such solution like gtkD, QtD, DWT
 are good, but for the long term the D community needs a D GUI library
 completly written in D.

 Just my thoughts
 °Matthias


 You do know that DWT is completely written in D? Don't you think we can
 create an environment for creating D GUI applications using DWT?


Yes, that would be an option. I have thought several times about that.
But I think, to get really acceptet by a wide range of developers, the 
library must be adjusted, to suit better the D coding style. This way we 
could get the whole power of D. But this also means that you get more 
and more away from the java path and sometime you are not able any more 
to merge changes in the java path to D.
So this means, this would really be a fork, not just a port.
(I hope, I have explained it correctly in my broken english, and I hope 
it sound not rude :|


°Matthias



 Apr 05 2011



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-04-05 15:25, Matthias Pleh wrote:

 Am 05.04.2011 15:06, schrieb Jacob Carlborg:

 On 2011-04-05 13:08, Matthias Pleh wrote:

 So I think for short or middle term such solution like gtkD, QtD, DWT
 are good, but for the long term the D community needs a D GUI library
 completly written in D.

 Just my thoughts
 °Matthias


 You do know that DWT is completely written in D? Don't you think we can
 create an environment for creating D GUI applications using DWT?


 Yes, that would be an option. I have thought several times about that.
 But I think, to get really acceptet by a wide range of developers, the
 library must be adjusted, to suit better the D coding style. This way we
 could get the whole power of D. But this also means that you get more
 and more away from the java path and sometime you are not able any more
 to merge changes in the java path to D.
 So this means, this would really be a fork, not just a port.
 (I hope, I have explained it correctly in my broken english, and I hope
 it sound not rude :|


 °Matthias


I see what you mean and I'm not seeing it as rude. It's hard to find a 
balance where it's still possible to merge future versions and taking 
full advantage of D.

-- 
/Jacob Carlborg



 Apr 05 2011



  parent reply Alvaro <alvaroDotSegura gmail.com>  writes:


El 05/04/2011 15:32, Jacob Carlborg escribió:

 On 2011-04-05 15:25, Matthias Pleh wrote:

 Am 05.04.2011 15:06, schrieb Jacob Carlborg:

 On 2011-04-05 13:08, Matthias Pleh wrote:

 So I think for short or middle term such solution like gtkD, QtD, DWT
 are good, but for the long term the D community needs a D GUI library
 completly written in D.

 Just my thoughts
 °Matthias


 You do know that DWT is completely written in D? Don't you think we can
 create an environment for creating D GUI applications using DWT?


 Yes, that would be an option. I have thought several times about that.
 But I think, to get really acceptet by a wide range of developers, the
 library must be adjusted, to suit better the D coding style. This way we
 could get the whole power of D. But this also means that you get more
 and more away from the java path and sometime you are not able any more
 to merge changes in the java path to D.
 So this means, this would really be a fork, not just a port.
 (I hope, I have explained it correctly in my broken english, and I hope
 it sound not rude :|


 °Matthias


 I see what you mean and I'm not seeing it as rude. It's hard to find a
 balance where it's still possible to merge future versions and taking
 full advantage of D.


DWT is an impressive achievement (as are gtkD and QtD), really. It's 
great what it can do without needing other languages. Nevertheless DWT 
might be in D and compile with D compilers, but looks more like "Dava" 
(Java-like D) :-)

I was expecting a real D system (kind of forgetting its SWT origin) and 
got a bit surprised when I browsed the code. Its very Java-ish (even 
contains D ports of String, Integer, Runnable, File, InputStream, etc.). 
What I mean is that I find it hard cosidering DWT "the One D GUI 
library". It would not do D justice.

But, ugh, I understand that it's more practical this way, so 
improvements in SWT can be adapted easily.

What would be the best solution? to D-ify more QtD? to D-ify DWT? gtkD? 
Would it be worth? Just keep them as they are?



 Apr 05 2011



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-04-05 23:15, Alvaro wrote:

 El 05/04/2011 15:32, Jacob Carlborg escribió:

 On 2011-04-05 15:25, Matthias Pleh wrote:

 Am 05.04.2011 15:06, schrieb Jacob Carlborg:

 On 2011-04-05 13:08, Matthias Pleh wrote:

 So I think for short or middle term such solution like gtkD, QtD, DWT
 are good, but for the long term the D community needs a D GUI library
 completly written in D.

 Just my thoughts
 °Matthias


 You do know that DWT is completely written in D? Don't you think we can
 create an environment for creating D GUI applications using DWT?


 Yes, that would be an option. I have thought several times about that.
 But I think, to get really acceptet by a wide range of developers, the
 library must be adjusted, to suit better the D coding style. This way we
 could get the whole power of D. But this also means that you get more
 and more away from the java path and sometime you are not able any more
 to merge changes in the java path to D.
 So this means, this would really be a fork, not just a port.
 (I hope, I have explained it correctly in my broken english, and I hope
 it sound not rude :|


 °Matthias


 I see what you mean and I'm not seeing it as rude. It's hard to find a
 balance where it's still possible to merge future versions and taking
 full advantage of D.


 DWT is an impressive achievement (as are gtkD and QtD), really. It's
 great what it can do without needing other languages. Nevertheless DWT
 might be in D and compile with D compilers, but looks more like "Dava"
 (Java-like D) :-)

 I was expecting a real D system (kind of forgetting its SWT origin) and
 got a bit surprised when I browsed the code. Its very Java-ish (even
 contains D ports of String, Integer, Runnable, File, InputStream, etc.).
 What I mean is that I find it hard cosidering DWT "the One D GUI
 library". It would not do D justice.

 But, ugh, I understand that it's more practical this way, so
 improvements in SWT can be adapted easily.

 What would be the best solution? to D-ify more QtD? to D-ify DWT? gtkD?
 Would it be worth? Just keep them as they are?


I think gtkD is out of the question since it's not using native 
controls. Don't know about QtD, if I recall correctly it, at least, 
looks quite native. But I would guess it would too hard to find whole 
int that, specially on Mac OS X.

-- 
/Jacob Carlborg



 Apr 06 2011



 next sibling parent  Jacob Carlborg <doob me.com>  writes:


On 2011-04-06 09:00, Jacob Carlborg wrote:

 On 2011-04-05 23:15, Alvaro wrote:

 El 05/04/2011 15:32, Jacob Carlborg escribió:

 On 2011-04-05 15:25, Matthias Pleh wrote:

 Am 05.04.2011 15:06, schrieb Jacob Carlborg:

 On 2011-04-05 13:08, Matthias Pleh wrote:

 So I think for short or middle term such solution like gtkD, QtD, DWT
 are good, but for the long term the D community needs a D GUI library
 completly written in D.

 Just my thoughts
 °Matthias


 You do know that DWT is completely written in D? Don't you think we
 can
 create an environment for creating D GUI applications using DWT?


 Yes, that would be an option. I have thought several times about that.
 But I think, to get really acceptet by a wide range of developers, the
 library must be adjusted, to suit better the D coding style. This
 way we
 could get the whole power of D. But this also means that you get more
 and more away from the java path and sometime you are not able any more
 to merge changes in the java path to D.
 So this means, this would really be a fork, not just a port.
 (I hope, I have explained it correctly in my broken english, and I hope
 it sound not rude :|


 °Matthias


 I see what you mean and I'm not seeing it as rude. It's hard to find a
 balance where it's still possible to merge future versions and taking
 full advantage of D.


 DWT is an impressive achievement (as are gtkD and QtD), really. It's
 great what it can do without needing other languages. Nevertheless DWT
 might be in D and compile with D compilers, but looks more like "Dava"
 (Java-like D) :-)

 I was expecting a real D system (kind of forgetting its SWT origin) and
 got a bit surprised when I browsed the code. Its very Java-ish (even
 contains D ports of String, Integer, Runnable, File, InputStream, etc.).
 What I mean is that I find it hard cosidering DWT "the One D GUI
 library". It would not do D justice.

 But, ugh, I understand that it's more practical this way, so
 improvements in SWT can be adapted easily.

 What would be the best solution? to D-ify more QtD? to D-ify DWT? gtkD?
 Would it be worth? Just keep them as they are?


 I think gtkD is out of the question since it's not using native
 controls. Don't know about QtD, if I recall correctly it, at least,
 looks quite native. But I would guess it would too hard to find whole
 int that, specially on Mac OS X.


That would be "find a hole in that" not "find whole int that".

-- 
/Jacob Carlborg



 Apr 06 2011



prev sibling  parent reply Matthias Pleh <jens konrad.net>  writes:


Am 06.04.2011 09:00, schrieb Jacob Carlborg:

 I think gtkD is out of the question since it's not using native
 controls. Don't know about QtD, if I recall correctly it, at least,
 looks quite native. But I would guess it would too hard to find whole
 int that, specially on Mac OS X.



Qt (and so QtD) use some native controls for Dialogs, e.g.: FilePicker, 
colorPicker, ... but most controls are drawn by the PaintEnginge. But Qt 
make really good job in imitating the native Theme. (except OSX, which 
is a little bit special)



 Apr 06 2011



 next sibling parent reply "Nick Sabalausky" <a a.a>  writes:


"Matthias Pleh" <jens konrad.net> wrote in message 
news:inh91t$1854$1 digitalmars.com...

 Am 06.04.2011 09:00, schrieb Jacob Carlborg:

 I think gtkD is out of the question since it's not using native
 controls. Don't know about QtD, if I recall correctly it, at least,
 looks quite native. But I would guess it would too hard to find whole
 int that, specially on Mac OS X.



 Qt (and so QtD) use some native controls for Dialogs, e.g.: FilePicker, 
 colorPicker, ... but most controls are drawn by the PaintEnginge. But Qt 
 make really good job in imitating the native Theme. (except OSX, which is 
 a little bit special)


My understanding is that Qt also has a compile-time flag that will make it 
actually use the real Win32 controls.



 Apr 06 2011



  parent reply Matthias Pleh <jens konrad.net>  writes:


Am 06.04.2011 11:40, schrieb Nick Sabalausky:

 "Matthias Pleh"<jens konrad.net>  wrote in message
 news:inh91t$1854$1 digitalmars.com...

 Am 06.04.2011 09:00, schrieb Jacob Carlborg:

 I think gtkD is out of the question since it's not using native
 controls. Don't know about QtD, if I recall correctly it, at least,
 looks quite native. But I would guess it would too hard to find whole
 int that, specially on Mac OS X.



 Qt (and so QtD) use some native controls for Dialogs, e.g.: FilePicker,
 colorPicker, ... but most controls are drawn by the PaintEnginge. But Qt
 make really good job in imitating the native Theme. (except OSX, which is
 a little bit special)


 My understanding is that Qt also has a compile-time flag that will make it
 actually use the real Win32 controls.


No! When compiling the Qt-library, you can specify a flag for the theme 
to build. The controls appears then with this theme.

On windows you can easaly test this, with Spy++.
I've just created a simple window with 
QHBoxLayout,QGridLayout,QGroupbox,Qlabel,QLineEdit,QTextEdit.
But ther is only one win32-control and this is the main-window!
You can see this also on the traffic of the windowsmessages.
This is so on Windows, maybe Qt use more native controls on other platforms?

The problem with OSX is, as I know, that some controls not only look 
different, but are also different arranged, and this make it more 
difficult to emulate.

°Matthias



 Apr 06 2011



 next sibling parent  Michel Fortin <michel.fortin michelf.com>  writes:


On 2011-04-06 07:38:30 -0400, Matthias Pleh <jens konrad.net> said:


 The problem with OSX is, as I know, that some controls not only look 
 different, but are also different arranged, and this make it more 
 difficult to emulate.


And it'll only become harder and harder. Have you seen in Mac OS X Lion 
the new tab control or the button groups (segmented controls in OS X 
parlance) which are now using an animated "slider" knob? And the new 
iOS-style scrollbars with a bounce effect? Nothing is impossible, but 
it'll take time for Qt to catch up with those changes.

<http://www.youtube.com/watch?v=B5k8x6jWXPw>

Meanwhile, Cocoa apps will get all this for free.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/



 Apr 06 2011



prev sibling  parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-04-06 13:38, Matthias Pleh wrote:

 Am 06.04.2011 11:40, schrieb Nick Sabalausky:

 "Matthias Pleh"<jens konrad.net> wrote in message
 news:inh91t$1854$1 digitalmars.com...

 Am 06.04.2011 09:00, schrieb Jacob Carlborg:

 I think gtkD is out of the question since it's not using native
 controls. Don't know about QtD, if I recall correctly it, at least,
 looks quite native. But I would guess it would too hard to find whole
 int that, specially on Mac OS X.



 Qt (and so QtD) use some native controls for Dialogs, e.g.: FilePicker,
 colorPicker, ... but most controls are drawn by the PaintEnginge. But Qt
 make really good job in imitating the native Theme. (except OSX,
 which is
 a little bit special)


 My understanding is that Qt also has a compile-time flag that will
 make it
 actually use the real Win32 controls.


 No! When compiling the Qt-library, you can specify a flag for the theme
 to build. The controls appears then with this theme.

 On windows you can easaly test this, with Spy++.
 I've just created a simple window with
 QHBoxLayout,QGridLayout,QGroupbox,Qlabel,QLineEdit,QTextEdit.
 But ther is only one win32-control and this is the main-window!
 You can see this also on the traffic of the windowsmessages.
 This is so on Windows, maybe Qt use more native controls on other
 platforms?

 The problem with OSX is, as I know, that some controls not only look
 different, but are also different arranged, and this make it more
 difficult to emulate.

 °Matthias


DWT handles that fine.

-- 
/Jacob Carlborg



 Apr 06 2011



  parent reply Matthias Pleh <jens konrad.net>  writes:


Am 06.04.2011 15:21, schrieb Jacob Carlborg:

 On 2011-04-06 13:38, Matthias Pleh wrote:

 Am 06.04.2011 11:40, schrieb Nick Sabalausky:

 "Matthias Pleh"<jens konrad.net> wrote in message
 news:inh91t$1854$1 digitalmars.com...

 Am 06.04.2011 09:00, schrieb Jacob Carlborg:

 I think gtkD is out of the question since it's not using native
 controls. Don't know about QtD, if I recall correctly it, at least,
 looks quite native. But I would guess it would too hard to find whole
 int that, specially on Mac OS X.



 Qt (and so QtD) use some native controls for Dialogs, e.g.: FilePicker,
 colorPicker, ... but most controls are drawn by the PaintEnginge.
 But Qt
 make really good job in imitating the native Theme. (except OSX,
 which is
 a little bit special)


 My understanding is that Qt also has a compile-time flag that will
 make it
 actually use the real Win32 controls.


 No! When compiling the Qt-library, you can specify a flag for the theme
 to build. The controls appears then with this theme.

 On windows you can easaly test this, with Spy++.
 I've just created a simple window with
 QHBoxLayout,QGridLayout,QGroupbox,Qlabel,QLineEdit,QTextEdit.
 But ther is only one win32-control and this is the main-window!
 You can see this also on the traffic of the windowsmessages.
 This is so on Windows, maybe Qt use more native controls on other
 platforms?

 The problem with OSX is, as I know, that some controls not only look
 different, but are also different arranged, and this make it more
 difficult to emulate.

 °Matthias


 DWT handles that fine.



Yeah, that's true.
You will only get the real platform feeling, when you use the native 
controls. I was always irritated by the unusual widget of swing.
So such an approach like DWT looks always handier, but don't forget,
you have to maintain all that code for _all_ platforms.
You always get pro's and con's.

°Matthias



 Apr 06 2011



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-04-06 16:37, Matthias Pleh wrote:

 Am 06.04.2011 15:21, schrieb Jacob Carlborg:

 On 2011-04-06 13:38, Matthias Pleh wrote:

 Am 06.04.2011 11:40, schrieb Nick Sabalausky:

 "Matthias Pleh"<jens konrad.net> wrote in message
 news:inh91t$1854$1 digitalmars.com...

 Am 06.04.2011 09:00, schrieb Jacob Carlborg:

 I think gtkD is out of the question since it's not using native
 controls. Don't know about QtD, if I recall correctly it, at least,
 looks quite native. But I would guess it would too hard to find whole
 int that, specially on Mac OS X.



 Qt (and so QtD) use some native controls for Dialogs, e.g.:
 FilePicker,
 colorPicker, ... but most controls are drawn by the PaintEnginge.
 But Qt
 make really good job in imitating the native Theme. (except OSX,
 which is
 a little bit special)


 My understanding is that Qt also has a compile-time flag that will
 make it
 actually use the real Win32 controls.


 No! When compiling the Qt-library, you can specify a flag for the theme
 to build. The controls appears then with this theme.

 On windows you can easaly test this, with Spy++.
 I've just created a simple window with
 QHBoxLayout,QGridLayout,QGroupbox,Qlabel,QLineEdit,QTextEdit.
 But ther is only one win32-control and this is the main-window!
 You can see this also on the traffic of the windowsmessages.
 This is so on Windows, maybe Qt use more native controls on other
 platforms?

 The problem with OSX is, as I know, that some controls not only look
 different, but are also different arranged, and this make it more
 difficult to emulate.

 °Matthias


 DWT handles that fine.



 Yeah, that's true.
 You will only get the real platform feeling, when you use the native
 controls. I was always irritated by the unusual widget of swing.
 So such an approach like DWT looks always handier, but don't forget,
 you have to maintain all that code for _all_ platforms.
 You always get pro's and con's.

 °Matthias


Yes that's true. I don't know how much different it would be compared to 
a non-native framework since there you have all the different themes to 
maintain.

-- 
/Jacob Carlborg



 Apr 06 2011



  parent reply Matthias Pleh <jens konrad.net>  writes:


 Yes that's true. I don't know how much different it would be compared to
 a non-native framework since there you have all the different themes to
 maintain.


Maybe, the best aproach would be, when you implement the basic framework 
flexible. E.g. a default rendering engine, where you can
draw you own controls, but keep it possible to add native controls.
So you always choose the best way, if a platform bring out a new control 
or a new look. But I down't know, if such different approaches
cann merged together?


BTW: under what license is DWT?
Can part of it relicensed under boost? (e.g. if we would reuse part of it)


°Matthias



 Apr 06 2011



  parent  Jacob Carlborg <doob me.com>  writes:


On 2011-04-06 17:34, Matthias Pleh wrote:

 Yes that's true. I don't know how much different it would be compared to
 a non-native framework since there you have all the different themes to
 maintain.


 Maybe, the best aproach would be, when you implement the basic framework
 flexible. E.g. a default rendering engine, where you can
 draw you own controls, but keep it possible to add native controls.
 So you always choose the best way, if a platform bring out a new control
 or a new look. But I down't know, if such different approaches
 cann merged together?


I don't know. It sounds like it could get really complicated.


 BTW: under what license is DWT?
 Can part of it relicensed under boost? (e.g. if we would reuse part of it)


It's licensed under the EPL license since that's the license used by 
SWT. So no. I don't know if you could do some kind of deal with the 
Eclipse foundation.


 °Matthias



-- 
/Jacob Carlborg



 Apr 06 2011



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2011-04-06 10:39, Matthias Pleh wrote:

 Am 06.04.2011 09:00, schrieb Jacob Carlborg:

 I think gtkD is out of the question since it's not using native
 controls. Don't know about QtD, if I recall correctly it, at least,
 looks quite native. But I would guess it would too hard to find whole
 int that, specially on Mac OS X.



 Qt (and so QtD) use some native controls for Dialogs, e.g.: FilePicker,
 colorPicker, ... but most controls are drawn by the PaintEnginge. But Qt
 make really good job in imitating the native Theme. (except OSX, which
 is a little bit special)


As expected. I'm not sure but it seems that Mac OS X Lion has a new 
style on the regular push buttons. Then Qt needs to start all over (almost).

-- 
/Jacob Carlborg



 Apr 06 2011



prev sibling  parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail>  writes:


On 05/04/2011 14:06, Jacob Carlborg wrote:

 On 2011-04-05 13:08, Matthias Pleh wrote:

 So I think for short or middle term such solution like gtkD, QtD, DWT
 are good, but for the long term the D community needs a D GUI library
 completly written in D.

 Just my thoughts
 °Matthias


 You do know that DWT is completely written in D?


Really? What about the parts of SWT that written in C? Or are those very 
small compared to the whole codebase?

-- 
Bruno Medeiros - Software Engineer



 Apr 07 2011



 next sibling parent reply Matthias Pleh <jens konrad.net>  writes:


Am 07.04.2011 21:38, schrieb Bruno Medeiros:

 On 05/04/2011 14:06, Jacob Carlborg wrote:

 On 2011-04-05 13:08, Matthias Pleh wrote:

 So I think for short or middle term such solution like gtkD, QtD, DWT
 are good, but for the long term the D community needs a D GUI library
 completly written in D.

 Just my thoughts
 °Matthias


 You do know that DWT is completely written in D?


 Really? What about the parts of SWT that written in C? Or are those very
 small compared to the whole codebase?




http://www.ohloh.net/p/swt/analyses/latest
http://www.ohloh.net/p/DWT/analyses/latest


greets
°Matthias



 Apr 07 2011



  parent reply Matthias Pleh <jens konrad.net>  writes:


Am 08.04.2011 00:08, schrieb Matthias Pleh:

 Am 07.04.2011 21:38, schrieb Bruno Medeiros:

 On 05/04/2011 14:06, Jacob Carlborg wrote:

 On 2011-04-05 13:08, Matthias Pleh wrote:

 So I think for short or middle term such solution like gtkD, QtD, DWT
 are good, but for the long term the D community needs a D GUI library
 completly written in D.

 Just my thoughts
 °Matthias


 You do know that DWT is completely written in D?


 Really? What about the parts of SWT that written in C? Or are those very
 small compared to the whole codebase?




 http://www.ohloh.net/p/swt/analyses/latest
 http://www.ohloh.net/p/DWT/analyses/latest


 greets
 °Matthias



BTW: 1.4 MLOC is really a huge codebase.
Hats off! You make a good job guys.


°Matthias



 Apr 07 2011



  parent reply Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


DWT is 3x the codebase size of SWT? 0o



 Apr 07 2011



 next sibling parent  Matthias Pleh <jens konrad.net>  writes:


Am 08.04.2011 00:27, schrieb Andrej Mitrovic:

 DWT is 3x the codebase size of SWT? 0o



Maybe the old portet versions in the branches directory?



 Apr 07 2011



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2011-04-08 00:27, Andrej Mitrovic wrote:

 DWT is 3x the codebase size of SWT? 0o


Don't know what code base he used for SWT but the DWT repository contains:

* 16 libraries from Eclipse
* 1 library from IBM
* 2 code bases for snippets
* 2 SWT platforms (I counted those as 1 in the above number)

So the DWT repository contains in total 20 different libraries/code bases.

-- 
/Jacob Carlborg



 Apr 08 2011



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2011-04-07 21:38, Bruno Medeiros wrote:

 On 05/04/2011 14:06, Jacob Carlborg wrote:

 On 2011-04-05 13:08, Matthias Pleh wrote:

 So I think for short or middle term such solution like gtkD, QtD, DWT
 are good, but for the long term the D community needs a D GUI library
 completly written in D.

 Just my thoughts
 °Matthias


 You do know that DWT is completely written in D?


 Really? What about the parts of SWT that written in C? Or are those very
 small compared to the whole codebase?


In SWT it's just the bindings which are written in C using JNI (these 
are generate automatically with a tool). Since D can link to C there's 
no need for any C code. Just bindings to the native libraries.

-- 
/Jacob Carlborg



 Apr 07 2011



prev sibling  parent reply Kagamin <spam here.lot>  writes:


Andrei Alexandrescu Wrote:


 On 4/4/11 8:36 PM, Nick Sabalausky wrote:

 "Daniel Gibson"<metalcaedes gmail.com>  wrote in message
 news:inddni$kmi$3 digitalmars.com...

 I don't know if wee need yet another GUI library.
 Are you sure Qt and DWT aren't good enough?


 AIUI:

 DWT doesn't support D2 (neither does wxD).


 
 I understand DWT does support D2 on Windows as of today:
 
 http://hg.dsource.org/projects/dwt2/rev/9f4c18c268b2
 
 
 Andrei
 


module java.lang.ThreadLocal;
lol



 Apr 05 2011



  parent  Jacob Carlborg <doob me.com>  writes:


On 2011-04-05 13:54, Kagamin wrote:

 Andrei Alexandrescu Wrote:


 On 4/4/11 8:36 PM, Nick Sabalausky wrote:

 "Daniel Gibson"<metalcaedes gmail.com>   wrote in message
 news:inddni$kmi$3 digitalmars.com...

 I don't know if wee need yet another GUI library.
 Are you sure Qt and DWT aren't good enough?


 AIUI:

 DWT doesn't support D2 (neither does wxD).


 I understand DWT does support D2 on Windows as of today:

 http://hg.dsource.org/projects/dwt2/rev/9f4c18c268b2


 Andrei


 module java.lang.ThreadLocal;
 lol


Hehe, yeah. Everything to make it easier to port future version of SWT.

-- 
/Jacob Carlborg



 Apr 05 2011