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


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

Don't forget Mac OSX.

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


 I don't know if wee need yet another GUI 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?

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


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

Don't forget Mac OSX.

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


 I don't know if wee need yet another GUI 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?

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
next sibling 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 "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 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 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
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


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

Don't forget Mac OSX.

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


 I don't know if wee need yet another GUI 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?

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


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

Don't forget Mac OSX.

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


 I don't know if wee need yet another GUI 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?

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.

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
prev sibling next 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

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 "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

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:

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 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 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 next sibling parent 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:

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
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 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 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 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 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 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 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
parent 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
prev sibling parent 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
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 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 next 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 "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
prev sibling next 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 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 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 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 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 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 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 next sibling parent 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
prev sibling 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 next 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 "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
prev sibling next sibling 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 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 next sibling parent 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
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling next sibling 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 next sibling parent "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
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling next sibling 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 next sibling parent 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
prev sibling 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 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 require DMD issue #5708 to be fixed. 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.
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. if(buttonWasPressed(triangle, 1)) // the 1 is player #1 // 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, send the event that player #2 pressed circle". Then, since everyone 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 make a pretty nifty GDI PacMan in C#: 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.

 if(buttonWasPressed(triangle, 1)) // the 1 is player #1
   // 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,
 send the event that player #2 pressed circle". Then, since everyone
 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 story/cutscene-fest or military shooter #5421 or some IP-tie-in...forgeddit.
 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 inlining working, so that may be a problem until DMD issue #5708 gets fixed: 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 :)

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 inlining working, so that may be a problem until DMD issue #5708 gets fixed: 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

Horrible waste of instructions doing another y<< 8 + y<< 6 when a simple "inc ax" would suffice!

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

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.

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.

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.

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 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 Gour-Gadadhara Dasa <gour atmarama.net> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 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
next sibling 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 - .Net with networking, GUI , Filesystem, ... -> all coded in C# (except 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 - .Net with networking, GUI , Filesystem, ... -> all coded in C# (except 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
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 Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
DWT is 3x the codebase size of SWT? 0o
Apr 07 2011
prev sibling parent 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