www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [GSoC] Container proposals by Ishan and Christian

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
We are honored to receive a fair amount of interest from students at our 
GSoC 2011.

One issue is that at least one student (who contacted me off-list) 
couldn't find a project to work on that would best play into his 
strengths. I think it's not too late to improve our GSoC ideas page 
(http://prowiki.org/wiki4d/wiki.cgi?GSOC_2011_Ideas).

Another issue is that we have competing proposals on identical or 
overlapping projects. I am trying to solve one of these matters 
privately, and I think it would be best if we could solve the others in 
the community.

I'm referring to Ishan's and Christian's proposals for containers. Both 
proposals have pros and cons, and I predict it would be very difficult 
to make a decision. Therefore, I'm trying to avoid that "by design", 
i.e. by finding a solution that would keep both busy on useful work that 
is in line with their capabilities.

First, I suggest that anyone interested gives a thorough read to the two 
proposals:

http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/ishanthilina/1

http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/murphy/1

Both students seem to be quite enthusiastic and capable. Two things that 
I'm worrying about are:

1. Both seem to be quite fresh on D, so they'll need close coaching at 
least in the beginning.

2. Both students seem unfamiliar with the STL, which is a difficult 
skill to acquire in a short time frame and is quite recommended for 
working on D's containers.

If the students could comment on that, that would be helpful.

Here's how I think we can solve the problem of overlapping projects:

1. One way is to convince one of the students to work on a different 
topic that would also play into his strengths and is of interest to him. 
Any suggestions are welcome, both from the students and the community.

2. Another approach would be to expand the scope of the project. There 
are plenty of interesting containers out there (see e.g. 
http://stackoverflow.com/questions/500607/what-are-the-lesser-known-but-c
ol-data-structures) 
that are darn useful. I suggest students to look over those and answer 
if they'd fell comfortable about implementing e.g. a Bloom filter or a trie.

With an expanded containers project we could (assuming all goes smooth) 
benefit of a host of solid containers by fall. The thing is that would 
definitely require very intensive mentoring. I'd probably be a mentor, 
and I'd need at least one to be comfortable about putting this option on 
the table.

Any thoughts, please share.


Thanks,

Andrei
Apr 03 2011
next sibling parent reply Matthias Pleh <matthias none.net> writes:
On 2011-04-03 21:05, Andrei Alexandrescu wrote:
 I think it's not too late to improve our GSoC ideas page

So here come my ideas There is still the lack of a good D Gui Library. Currently some GUI's are still under development (most projects on dsoure are abandoned!), but none of them are really perfect D-GUI's * GtkD -> good and stable, but a D wrapper around a C-library * DWT -> also good, but a port from Java and not really D-like coded * DFL -> windows only, a way too .Net-like, is currently not very active (abandoned?) * ... all others I know are unmature and abandoned (tell me, if I'm wrong here!) So there comes 2 ideas to my mind: - Abstraction Layer for OS independent (Win/Linux/OSX/?) GUI development * Just basic structures/functions/classes for Window creation, event handling, ... This could be used not only by a Standard-D-Gui-library, but also by other Gui-libraries for D - Design of a OS independent GUI-toolkit * class-diagramm, basicstuctures, ... This could be the beginning of a Community-driven development of a good D-GUI-library which eventualy could find its way into phobos ... ?
Apr 03 2011
next sibling parent Matthias Pleh <matthias none.net> writes:
On 2011-04-03 23:23, Matthias Pleh wrote:
 * GtkD -> good and stable, but a D wrapper around a C-library
 * DWT  -> also good, but a port from Java and not really D-like coded
 * DFL  -> windows only, a way too .Net-like, is currently not very
 active (abandoned?)

Ok, I've forgotten some * QtD -> the same as GtkD, just a wrapper * dgui -> windows only, also really .Net-like Maybe there are more?
Apr 03 2011
prev sibling next sibling parent reply spir <denis.spir gmail.com> writes:
On 04/03/2011 11:23 PM, Matthias Pleh wrote:
 So there comes 2 ideas to my mind:


 - Abstraction Layer for OS independent (Win/Linux/OSX/?) GUI development
    * Just basic structures/functions/classes for Window creation,
    event handling, ...
    This could be used not only by a Standard-D-Gui-library,
    but also by other Gui-libraries for D

Do you mean something analog to the database-access interface project, but for GUI? (Meaning a standard GUI-programming interface for D.) If yes, I find this *very* interesting, and certainly highly useful for the language. However, it may be somewhat complicated (but that's the charm of it ;-) because of differences of design in existing GUI frameworks, of the the bigger complexity of GUI programming on the other; and there may be no prior work.
 - Design of a OS independent GUI-toolkit
    * class-diagramm, basicstuctures, ...

A fairly big project, I guess! (even for a toy...) Denis -- _________________ vita es estrany spir.wikidot.com
Apr 03 2011
parent reply Matthias Pleh <matthias none.net> writes:
On 2011-04-03 23:48, spir wrote:
 (Meaning a standard GUI-programming interface for D.)

Yes, exactly! Just a really small Api to abstract the OS. - Application -> as a representation for the process - Window -> create, show, hide - Canvas/Image -> to draw on + No buttons/textbox or other widgets, this would be part of the higher level (some GUI's on this basic API could use native controls / others may draw it itself / or draw it with GPU ... I mean, there were several attempts to create a GUI, each with a different approach, and most of them are unfinished and abandoned. This could be a base for all GUI's
 A fairly big project, I guess! (even for a toy...)

It haven't to be complete. Just a start, with the most important corner cases. - Matthias
Apr 03 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 04.04.2011 00:36, schrieb Jonathan M Davis:
 On 2011-04-03 15:11, Matthias Pleh wrote:
 On 2011-04-03 23:48, spir wrote:
 (Meaning a standard GUI-programming interface for D.)

Yes, exactly! Just a really small Api to abstract the OS. - Application -> as a representation for the process - Window -> create, show, hide - Canvas/Image -> to draw on + No buttons/textbox or other widgets, this would be part of the higher level (some GUI's on this basic API could use native controls / others may draw it itself / or draw it with GPU ... I mean, there were several attempts to create a GUI, each with a different approach, and most of them are unfinished and abandoned. This could be a base for all GUI's > A fairly big project, I guess! (even for a toy...) It haven't to be complete. Just a start, with the most important corner cases.

I do _not_ think that generic GUI layer is a good idea. GUI toolkits all act very differently about a lot of things. Abstracting them is not easy and tends to result in you losing a lot of their power. It's better to just use the appropriate GUI toolkit and be done with it. Only a _very_ simple GUI application would ultimately be very well served by a generic GUI layer. Not to mention, that's just adding yet _another_ layer of abstraction on top of who knows how many layers of abstraction, and D is supposed to be a _systems_ programming language. Extra layers of abstraction generally harm efficiency, and in this case, they don't really help the programmer all that much in writing their application anyway. You just can't abstract diverse GUI toolkits in an efficient or particularly useful manner. Only the really simplistic stuff would work. What we need is for projects such as qtd to get the proper support that they need to make progress and be completed. - Jonathan M Davis

I agree. And please: let's not do it the Java Swing way, i.e. look and feel crappy and out of place on any platform for the sake of being consistent between platforms. Cheers, - Daniel
Apr 03 2011
parent Matthias Pleh <jens konrad.net> writes:
Am 04.04.2011 01:09, schrieb Daniel Gibson:
 I agree.
 And please: let's not do it the Java Swing way, i.e. look and feel
 crappy and out of place on any platform for the sake of being consistent
 between platforms.

Java Swing is an extreme example. Everything is selfdrawn. Qt makes it much better. Most widgets are selfdrawn. Only some use the native widgets, e.g. Filepicker, ContextMenu, ... Matthias
Apr 04 2011
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2011-04-03 18:11:38 -0400, Matthias Pleh <matthias none.net> said:

 On 2011-04-03 23:48, spir wrote:
 (Meaning a standard GUI-programming interface for D.)

Yes, exactly! Just a really small Api to abstract the OS. - Application -> as a representation for the process - Window -> create, show, hide - Canvas/Image -> to draw on + No buttons/textbox or other widgets, this would be part of the higher level (some GUI's on this basic API could use native controls / others may draw it itself / or draw it with GPU ...

I wouldn't build a GUI on top of that, but having a standard way to open a window and draw things in it would be great for prototyping algorithms or to make simple data visualization programs, or just make it fun to learn programming. I did something similar for C++ at the request of a professor as a summer project when I was at the university... -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Apr 03 2011
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Matthias Pleh (matthias none.net)'s article
 On 2011-04-03 21:05, Andrei Alexandrescu wrote:
 * DFL  -> windows only, a way too .Net-like, is currently not very
 active (abandoned?)

Not abandoned, just updated very sparsely. The DFL API is IMHO much easier to use than GtkD, which is why I wrote the first version of my Plot2kill lib for it before I ran into limitations I couldn't get around. (These were mainly lack of support for non-Windows OS's and lack of builtin vector graphics support a la GTK-Cairo.) I wonder how hard it would be to port DFL to Linux using Winelib. Wine's gotten pretty good lately, and the whole point of Winelib is to compile code that calls the Windows API on Linux. (Wine is for running Windows **binaries**, but it has a companion library, Winelib, for **compiling** Windows API code to native Linux binaries.)
Apr 03 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 04.04.2011 01:11, schrieb dsimcha:
 == Quote from Matthias Pleh (matthias none.net)'s article
 On 2011-04-03 21:05, Andrei Alexandrescu wrote:
 * DFL  ->  windows only, a way too .Net-like, is currently not very
 active (abandoned?)

Not abandoned, just updated very sparsely. The DFL API is IMHO much easier to use than GtkD, which is why I wrote the first version of my Plot2kill lib for it before I ran into limitations I couldn't get around. (These were mainly lack of support for non-Windows OS's and lack of builtin vector graphics support a la GTK-Cairo.) I wonder how hard it would be to port DFL to Linux using Winelib. Wine's gotten pretty good lately, and the whole point of Winelib is to compile code that calls the Windows API on Linux. (Wine is for running Windows **binaries**, but it has a companion library, Winelib, for **compiling** Windows API code to native Linux binaries.)

May be possible, but would probably look crappy - just like windows applications in wine look crappy (as long as you don't have a win2k like theme for GTK/QT so all your applications look like windows applications..). This may be acceptable to port or emulate windows applications, but not for developing new cross-platform applications. SWT looks great (==native) on Windows and Linux/GTK (probably also OSX?), so why not push DWT? Don't know what programming for it is like, though. Cheers, - Daniel
Apr 03 2011
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Daniel Gibson (metalcaedes gmail.com)'s article
 May be possible, but would probably look crappy - just like windows
 applications in wine look crappy (as long as you don't have a win2k like
 theme for GTK/QT so all your applications look like windows applications..).
 This may be acceptable to port or emulate windows applications, but not
 for developing new cross-platform applications.

IDK why people are bothered so much by this. I hate Swing only because it's so sluggish-feeling, but GTK on Windows doesn't bother me even though it looks non-native. Similarly, I doubt DFL on Linux would bother me if I used Linux as my desktop OS.
 SWT looks great (==native) on Windows and Linux/GTK (probably also
 OSX?), so why not push DWT? Don't know what programming for it is like,
 though.

My only gripe with DWT is, AFAIK, it doesn't work for D2 yet and I've got too much other stuff on my plate to fix this myself.
Apr 03 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 04.04.2011 01:38, schrieb dsimcha:
 == Quote from Daniel Gibson (metalcaedes gmail.com)'s article
 May be possible, but would probably look crappy - just like windows
 applications in wine look crappy (as long as you don't have a win2k like
 theme for GTK/QT so all your applications look like windows applications..).
 This may be acceptable to port or emulate windows applications, but not
 for developing new cross-platform applications.

IDK why people are bothered so much by this. I hate Swing only because it's so sluggish-feeling, but GTK on Windows doesn't bother me even though it looks non-native. Similarly, I doubt DFL on Linux would bother me if I used Linux as my desktop OS.
 SWT looks great (==native) on Windows and Linux/GTK (probably also
 OSX?), so why not push DWT? Don't know what programming for it is like,
 though.

My only gripe with DWT is, AFAIK, it doesn't work for D2 yet and I've got too much other stuff on my plate to fix this myself.

I think Jacob Carlborg mentioned that he was working on that recently. Also there was a commit to dwt2's hg 2 weeks ago by somebody else ("kntroh") "Update to compile and execute with dmd 2.052." so it /may/ work. BTW: Besides looking crappy (which could probably be fixed with theme-support) my main issue with non-native GUIs is that they don't have standard filepickers. The GTK filepicker allows to save bookmarks to directorys and not having those annoys me. Furthermore those filepickers often just suck usability-wise. Cheers, - Daniel
Apr 03 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-04-04 01:50, Daniel Gibson wrote:
 Am 04.04.2011 01:38, schrieb dsimcha:
 == Quote from Daniel Gibson (metalcaedes gmail.com)'s article
 May be possible, but would probably look crappy - just like windows
 applications in wine look crappy (as long as you don't have a win2k like
 theme for GTK/QT so all your applications look like windows applications..).
 This may be acceptable to port or emulate windows applications, but not
 for developing new cross-platform applications.

IDK why people are bothered so much by this. I hate Swing only because it's so sluggish-feeling, but GTK on Windows doesn't bother me even though it looks non-native. Similarly, I doubt DFL on Linux would bother me if I used Linux as my desktop OS.
 SWT looks great (==native) on Windows and Linux/GTK (probably also
 OSX?), so why not push DWT? Don't know what programming for it is like,
 though.

My only gripe with DWT is, AFAIK, it doesn't work for D2 yet and I've got too much other stuff on my plate to fix this myself.

I think Jacob Carlborg mentioned that he was working on that recently. Also there was a commit to dwt2's hg 2 weeks ago by somebody else ("kntroh") "Update to compile and execute with dmd 2.052." so it /may/ work.

This is correct. I got a patch from kntroh and DWT should work with D2 on Windows.
 BTW: Besides looking crappy (which could probably be fixed with
 theme-support) my main issue with non-native GUIs is that they don't
 have standard filepickers.
 The GTK filepicker allows to save bookmarks to directorys and not having
 those annoys me. Furthermore those filepickers often just suck
 usability-wise.

 Cheers,
 - Daniel

-- /Jacob Carlborg
Apr 04 2011
prev sibling next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 04.04.2011 01:46, schrieb Jonathan M Davis:
 On 2011-04-03 16:38, dsimcha wrote:
 == Quote from Daniel Gibson (metalcaedes gmail.com)'s article

 May be possible, but would probably look crappy - just like windows
 applications in wine look crappy (as long as you don't have a win2k like
 theme for GTK/QT so all your applications look like windows
 applications..). This may be acceptable to port or emulate windows
 applications, but not for developing new cross-platform applications.

IDK why people are bothered so much by this. I hate Swing only because it's so sluggish-feeling, but GTK on Windows doesn't bother me even though it looks non-native. Similarly, I doubt DFL on Linux would bother me if I used Linux as my desktop OS.
 SWT looks great (==native) on Windows and Linux/GTK (probably also
 OSX?), so why not push DWT? Don't know what programming for it is like,
 though.

My only gripe with DWT is, AFAIK, it doesn't work for D2 yet and I've got too much other stuff on my plate to fix this myself.

If swing actually had a good-looking look and feel, it probably wouldn't be that big a problem, but it's ugly. Still, for a lot of people, the fact that something doesn't look native is a major problem. Regardless, SWT has a great solution to making the GUI look native and generally is extremely well-designed as I understand it (though unfortunately, it considers GTK to be native on Linux, and I hate the look of GTK).

Maybe http://code.google.com/a/eclipselabs.org/p/swtqt/ could fix that for you? Don't know how stable and maintained that is, though. Cheers, - Daniel
Apr 03 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-04-04 01:58, Daniel Gibson wrote:
 Am 04.04.2011 01:46, schrieb Jonathan M Davis:
 On 2011-04-03 16:38, dsimcha wrote:
 == Quote from Daniel Gibson (metalcaedes gmail.com)'s article

 May be possible, but would probably look crappy - just like windows
 applications in wine look crappy (as long as you don't have a win2k like
 theme for GTK/QT so all your applications look like windows
 applications..). This may be acceptable to port or emulate windows
 applications, but not for developing new cross-platform applications.

IDK why people are bothered so much by this. I hate Swing only because it's so sluggish-feeling, but GTK on Windows doesn't bother me even though it looks non-native. Similarly, I doubt DFL on Linux would bother me if I used Linux as my desktop OS.
 SWT looks great (==native) on Windows and Linux/GTK (probably also
 OSX?), so why not push DWT? Don't know what programming for it is like,
 though.

My only gripe with DWT is, AFAIK, it doesn't work for D2 yet and I've got too much other stuff on my plate to fix this myself.

If swing actually had a good-looking look and feel, it probably wouldn't be that big a problem, but it's ugly. Still, for a lot of people, the fact that something doesn't look native is a major problem. Regardless, SWT has a great solution to making the GUI look native and generally is extremely well-designed as I understand it (though unfortunately, it considers GTK to be native on Linux, and I hate the look of GTK).

Maybe http://code.google.com/a/eclipselabs.org/p/swtqt/ could fix that for you? Don't know how stable and maintained that is, though. Cheers, - Daniel

That's interesting. -- /Jacob Carlborg
Apr 04 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-04-04 01:38, dsimcha wrote:
 == Quote from Daniel Gibson (metalcaedes gmail.com)'s article
 May be possible, but would probably look crappy - just like windows
 applications in wine look crappy (as long as you don't have a win2k like
 theme for GTK/QT so all your applications look like windows applications..).
 This may be acceptable to port or emulate windows applications, but not
 for developing new cross-platform applications.

IDK why people are bothered so much by this. I hate Swing only because it's so sluggish-feeling, but GTK on Windows doesn't bother me even though it looks non-native. Similarly, I doubt DFL on Linux would bother me if I used Linux as my desktop OS.
 SWT looks great (==native) on Windows and Linux/GTK (probably also
 OSX?), so why not push DWT? Don't know what programming for it is like,
 though.

My only gripe with DWT is, AFAIK, it doesn't work for D2 yet and I've got too much other stuff on my plate to fix this myself.

I was planing to give this a proper announcement when the linux version is working as well but anyway: DWT works with D2 on Windows. http://hg.dsource.org/projects/dwt2 -- /Jacob Carlborg
Apr 04 2011
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/4/11 3:55 AM, Jacob Carlborg wrote:
 On 2011-04-04 01:38, dsimcha wrote:
 == Quote from Daniel Gibson (metalcaedes gmail.com)'s article
 May be possible, but would probably look crappy - just like windows
 applications in wine look crappy (as long as you don't have a win2k like
 theme for GTK/QT so all your applications look like windows
 applications..).
 This may be acceptable to port or emulate windows applications, but not
 for developing new cross-platform applications.

IDK why people are bothered so much by this. I hate Swing only because it's so sluggish-feeling, but GTK on Windows doesn't bother me even though it looks non-native. Similarly, I doubt DFL on Linux would bother me if I used Linux as my desktop OS.
 SWT looks great (==native) on Windows and Linux/GTK (probably also
 OSX?), so why not push DWT? Don't know what programming for it is like,
 though.

My only gripe with DWT is, AFAIK, it doesn't work for D2 yet and I've got too much other stuff on my plate to fix this myself.

I was planing to give this a proper announcement when the linux version is working as well but anyway: DWT works with D2 on Windows. http://hg.dsource.org/projects/dwt2

You may want to post that to reddit. Andrei
Apr 04 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-04-04 16:08, Andrej Mitrovic wrote:
 On 4/4/11, Jacob Carlborg<doob me.com>  wrote:
 I was planing to give this a proper announcement when the linux version
 is working as well but anyway: DWT works with D2 on Windows.

 http://hg.dsource.org/projects/dwt2

How do we build? I've tried `rake all`, but I get back errors: https://gist.github.com/901684

Oh, I probably should have mentioned that I'm currently only updating the base and SWT libraries, so run "rake base swt". The SWT snippets also compile: "rake swtsnippets". -- /Jacob Carlborg
Apr 04 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-04-04 20:55, Andrej Mitrovic wrote:
 On 4/4/11, Jacob Carlborg<doob me.com>  wrote:
 Oh, I probably should have mentioned that I'm currently only updating
 the base and SWT libraries, so run "rake base swt". The SWT snippets
 also compile: "rake swtsnippets".

Yeah that worked. However not all of the snippets managed to compile, and some of them fail at runtime. Most seem to work though.

Yeah I know, some of the fail at runtime, I think some of them always did that. But I'm pretty sure all should compile. -- /Jacob Carlborg
Apr 04 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-04-04 01:46, Jonathan M Davis wrote:
 On 2011-04-03 16:38, dsimcha wrote:
 == Quote from Daniel Gibson (metalcaedes gmail.com)'s article

 May be possible, but would probably look crappy - just like windows
 applications in wine look crappy (as long as you don't have a win2k like
 theme for GTK/QT so all your applications look like windows
 applications..). This may be acceptable to port or emulate windows
 applications, but not for developing new cross-platform applications.

IDK why people are bothered so much by this. I hate Swing only because it's so sluggish-feeling, but GTK on Windows doesn't bother me even though it looks non-native. Similarly, I doubt DFL on Linux would bother me if I used Linux as my desktop OS.
 SWT looks great (==native) on Windows and Linux/GTK (probably also
 OSX?), so why not push DWT? Don't know what programming for it is like,
 though.

My only gripe with DWT is, AFAIK, it doesn't work for D2 yet and I've got too much other stuff on my plate to fix this myself.

If swing actually had a good-looking look and feel, it probably wouldn't be that big a problem, but it's ugly. Still, for a lot of people, the fact that something doesn't look native is a major problem. Regardless, SWT has a great solution to making the GUI look native and generally is extremely well-designed as I understand it (though unfortunately, it considers GTK to be native on Linux, and I hate the look of GTK). Pretty much every major Java GUI application that I'm aware of uses SWT, not swing.

I think the reason why Eclipse chose GTK and not Qt is the previous license issues, GPL and EPL is not compatible. Now this is no longer a problem and I've heard that someone is working on a Qt port of SWT, don't know the status. Anyone is also free to make a Qt port of DWT.
 It would certainly be great if DWT were brought up-to-date at some point, but
 personally, I'm far more likely to pick qtd if I do a GUI application, simply
 because I use KDE, and qtd would look native on my desktop and generally
 integrate better (and it would still be cross platform). I don't do much in
 the way of GUI applications though.

Have a look at my answer to dsimcha.
 - Jonathan M Davis

-- /Jacob Carlborg
Apr 04 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-04-03 16:38, dsimcha wrote:
 == Quote from Daniel Gibson (metalcaedes gmail.com)'s article
 
 May be possible, but would probably look crappy - just like windows
 applications in wine look crappy (as long as you don't have a win2k like
 theme for GTK/QT so all your applications look like windows
 applications..). This may be acceptable to port or emulate windows
 applications, but not for developing new cross-platform applications.

IDK why people are bothered so much by this. I hate Swing only because it's so sluggish-feeling, but GTK on Windows doesn't bother me even though it looks non-native. Similarly, I doubt DFL on Linux would bother me if I used Linux as my desktop OS.
 SWT looks great (==native) on Windows and Linux/GTK (probably also
 OSX?), so why not push DWT? Don't know what programming for it is like,
 though.

My only gripe with DWT is, AFAIK, it doesn't work for D2 yet and I've got too much other stuff on my plate to fix this myself.

If swing actually had a good-looking look and feel, it probably wouldn't be that big a problem, but it's ugly. Still, for a lot of people, the fact that something doesn't look native is a major problem. Regardless, SWT has a great solution to making the GUI look native and generally is extremely well-designed as I understand it (though unfortunately, it considers GTK to be native on Linux, and I hate the look of GTK). Pretty much every major Java GUI application that I'm aware of uses SWT, not swing. It would certainly be great if DWT were brought up-to-date at some point, but personally, I'm far more likely to pick qtd if I do a GUI application, simply because I use KDE, and qtd would look native on my desktop and generally integrate better (and it would still be cross platform). I don't do much in the way of GUI applications though. - Jonathan M Davis
Apr 03 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-04-04 01:14, Daniel Gibson wrote:
 Am 04.04.2011 01:11, schrieb dsimcha:
 == Quote from Matthias Pleh (matthias none.net)'s article
 On 2011-04-03 21:05, Andrei Alexandrescu wrote:
 * DFL -> windows only, a way too .Net-like, is currently not very
 active (abandoned?)

Not abandoned, just updated very sparsely. The DFL API is IMHO much easier to use than GtkD, which is why I wrote the first version of my Plot2kill lib for it before I ran into limitations I couldn't get around. (These were mainly lack of support for non-Windows OS's and lack of builtin vector graphics support a la GTK-Cairo.) I wonder how hard it would be to port DFL to Linux using Winelib. Wine's gotten pretty good lately, and the whole point of Winelib is to compile code that calls the Windows API on Linux. (Wine is for running Windows **binaries**, but it has a companion library, Winelib, for **compiling** Windows API code to native Linux binaries.)

May be possible, but would probably look crappy - just like windows applications in wine look crappy (as long as you don't have a win2k like theme for GTK/QT so all your applications look like windows applications..). This may be acceptable to port or emulate windows applications, but not for developing new cross-platform applications. SWT looks great (==native) on Windows and Linux/GTK (probably also OSX?), so why not push DWT? Don't know what programming for it is like, though.

I think the SWT API is really nice. The Mac OS X port is still in progress. Later versions of SWT looks more native on osx, sheets and native toolbars.
 Cheers,
 - Daniel

-- /Jacob Carlborg
Apr 04 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/4/11, Jacob Carlborg <doob me.com> wrote:
 I was planing to give this a proper announcement when the linux version
 is working as well but anyway: DWT works with D2 on Windows.

 http://hg.dsource.org/projects/dwt2

How do we build? I've tried `rake all`, but I get back errors: https://gist.github.com/901684
Apr 04 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/4/11, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 On 4/4/11, Jacob Carlborg <doob me.com> wrote:
 I was planing to give this a proper announcement when the linux version
 is working as well but anyway: DWT works with D2 on Windows.

 http://hg.dsource.org/projects/dwt2

How do we build? I've tried `rake all`, but I get back errors: https://gist.github.com/901684

Oops nevermind, I should have used `rake base swt`.
Apr 04 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/4/11, Jacob Carlborg <doob me.com> wrote:
 Oh, I probably should have mentioned that I'm currently only updating
 the base and SWT libraries, so run "rake base swt". The SWT snippets
 also compile: "rake swtsnippets".

Yeah that worked. However not all of the snippets managed to compile, and some of them fail at runtime. Most seem to work though.
Apr 04 2011
prev sibling next sibling parent reply Jens Mueller <jens.k.mueller gmx.de> writes:
Andrei Alexandrescu wrote:
 We are honored to receive a fair amount of interest from students at
 our GSoC 2011.
 
 One issue is that at least one student (who contacted me off-list)
 couldn't find a project to work on that would best play into his
 strengths. I think it's not too late to improve our GSoC ideas page
 (http://prowiki.org/wiki4d/wiki.cgi?GSOC_2011_Ideas).
 
 Another issue is that we have competing proposals on identical or
 overlapping projects. I am trying to solve one of these matters
 privately, and I think it would be best if we could solve the others
 in the community.
 
 I'm referring to Ishan's and Christian's proposals for containers.
 Both proposals have pros and cons, and I predict it would be very
 difficult to make a decision. Therefore, I'm trying to avoid that
 "by design", i.e. by finding a solution that would keep both busy on
 useful work that is in line with their capabilities.
 
 First, I suggest that anyone interested gives a thorough read to the
 two proposals:
 
 http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/ishanthilina/1

That proposal is not made public. I.e. I cannot access it.
 http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/murphy/1
 
 Both students seem to be quite enthusiastic and capable. Two things
 that I'm worrying about are:
 
 1. Both seem to be quite fresh on D, so they'll need close coaching
 at least in the beginning.
 
 2. Both students seem unfamiliar with the STL, which is a difficult
 skill to acquire in a short time frame and is quite recommended for
 working on D's containers.

Both valid points. I'd like to help. But how do I know that I'm familiar with the STL? It's containers and generic algorithms glued together via iterators. I've read Effective STL and used the STL but I have never looked at an implementation of the STL. On rare occasions I dived into GNU STL to figure out what was going on. Regarding the former: They should start reading your book, if they haven't. What do you mean by coaching? Looking at their code and giving feedback?
 If the students could comment on that, that would be helpful.
 
 Here's how I think we can solve the problem of overlapping projects:
 
 1. One way is to convince one of the students to work on a different
 topic that would also play into his strengths and is of interest to
 him. Any suggestions are welcome, both from the students and the
 community.
 
 2. Another approach would be to expand the scope of the project.
 There are plenty of interesting containers out there (see e.g.
http://stackoverflow.com/questions/500607/what-are-the-lesser-known-but-cool-data-structures)
 that are darn useful. I suggest students to look over those and
 answer if they'd fell comfortable about implementing e.g. a Bloom

That is a nice list. I myself don't know most of these. I find extending each project with an additional data structure more appealing. But the students have to decide between those two options. I like the second one more because then I learn something new.
 With an expanded containers project we could (assuming all goes
 smooth) benefit of a host of solid containers by fall. The thing is
 that would definitely require very intensive mentoring. I'd probably
 be a mentor, and I'd need at least one to be comfortable about
 putting this option on the table.

Can you express intensive monitoring in hours per week from your experience? BTW I never introduced myself and seeing all of the students submitting proposals and gently introducing themselves I feel kind of cheap. The applications are very good. My name is Jens Mueller. I earned my CS degree from Humboldt University Berlin in 2008. Currently I'm struggling as a PhD student. Jens
Apr 03 2011
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/3/11 5:06 PM, Jens Mueller wrote:
 Andrei Alexandrescu wrote:
 We are honored to receive a fair amount of interest from students at
 our GSoC 2011.

 One issue is that at least one student (who contacted me off-list)
 couldn't find a project to work on that would best play into his
 strengths. I think it's not too late to improve our GSoC ideas page
 (http://prowiki.org/wiki4d/wiki.cgi?GSOC_2011_Ideas).

 Another issue is that we have competing proposals on identical or
 overlapping projects. I am trying to solve one of these matters
 privately, and I think it would be best if we could solve the others
 in the community.

 I'm referring to Ishan's and Christian's proposals for containers.
 Both proposals have pros and cons, and I predict it would be very
 difficult to make a decision. Therefore, I'm trying to avoid that
 "by design", i.e. by finding a solution that would keep both busy on
 useful work that is in line with their capabilities.

 First, I suggest that anyone interested gives a thorough read to the
 two proposals:

 http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/ishanthilina/1

That proposal is not made public. I.e. I cannot access it.

Thanks for letting me know. I made sure I logged out before trying it, but probably I was still logged in in gmail. I think I need at this point to ask the students to allow me to make their proposals public. Andrei
Apr 03 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/3/11 5:06 PM, Jens Mueller wrote:
 Andrei Alexandrescu wrote:
 1. Both seem to be quite fresh on D, so they'll need close coaching
 at least in the beginning.

 2. Both students seem unfamiliar with the STL, which is a difficult
 skill to acquire in a short time frame and is quite recommended for
 working on D's containers.

Both valid points. I'd like to help. But how do I know that I'm familiar with the STL? It's containers and generic algorithms glued together via iterators. I've read Effective STL and used the STL but I have never looked at an implementation of the STL. On rare occasions I dived into GNU STL to figure out what was going on.

That would be "STL internals". If you've used the STL systematically then it can be assumed you're familiar with it.
 Regarding the former: They should start reading your book, if they
 haven't. What do you mean by coaching? Looking at their code and giving
 feedback?

More than that: guiding the next step. That would entail understanding the high level issues quite well.
 With an expanded containers project we could (assuming all goes
 smooth) benefit of a host of solid containers by fall. The thing is
 that would definitely require very intensive mentoring. I'd probably
 be a mentor, and I'd need at least one to be comfortable about
 putting this option on the table.

Can you express intensive monitoring in hours per week from your experience?

I don't have experience as a GSoC mentor, but I assume it should be doable in addition to a normal job. The main challenge is having the background. Andrei
Apr 03 2011
parent reply Christian Hotz-Behofsits <chris.hotz.behofsits gmail.com> writes:
Hi there!

Now I read Ishan's idea of a expansion of the scope and I think it's a
good one! We can split a greater topic in smaller ones and can
complement each other! There are a lot of cool containers and so the
library would get even mightier.

Now we are prepared (I ordered some books on that topic last week) and
another topic would be like a setback!
Apr 07 2011
parent reply Christian Hotz-Behofsits <chris.hotz.behofsits gmail.com> writes:
I thought a lot about the project, the possibility to switch to
other topics and why I really want to work on containers. So I wrote
to Ishan (I don&#8217;t know the other students) and we discussed all day
long. It was a fulfilling and positiv conversation with a clear
result:
We both would like to work on containers in a way of cooperation[1]
- Containers are a big topic and so we can make D to a really
powerful language. I like them, because they have a very
interresting theoretical side and they consists of logical
considerations.

I have to admit that I&#8217;m not a data structure expert and I haven&#8217;t
knew what a blooming filter is until I looked it up, but: Who fights
can lose, who doesn't fight has already lost.

And no, we are not stubborn - we only know what we want :-)

[1]Same topic, but not on the same data structures.
Apr 09 2011
parent Ishan Thilina <ishanthilina gmail.com> writes:
I thought a lot about the project, the possibility to switch to
other topics and why I really want to work on containers. So I wrote
to Ishan (I don&#8217;t know the other students) and we discussed all day
long. It was a fulfilling and positiv conversation with a clear
result:

Yes, Christian did mail me regarding this matter :-) .
We both would like to work on containers in a way of cooperation[1]
- Containers are a big topic and so we can make D to a really
powerful language. I like them, because they have a very
interresting theoretical side and they consists of logical
considerations.

Yes, I agree with Christian. Containers are a big topic and you can add much as you like to make it even bigger. (The scope will just keep expanding ;) ). So the topic contains enough work to be covered by two students. So who ever the students that gets selected to do the project should be able to cooperate with the other student. We must not forget that at the end of the day the whole work that is done goes to the benefit of the company no matter who ever does it. Mr. Alexandrescu points out from the email he sent to the GSoC participants before the application deadlines that "we will allow only 1-2 applications on containers" . So there is a possibility of the container project getting two students accepted. As the D community we should come up with a plan to decide which data structures should be implemented and seperate and assign them between the students. It's another story if only one student gets selected to the project, but it is always good to be prepared early. So if we start early we will be able to create a solid and a well seperated two project plans on containers before 25th of Apr letting the students who gets selected( whoever they are) for the project to start the work early without debating on which data structures to implement. Earlier the project starts more data structures will be created ( --> more for D :-D)...!
Apr 10 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-04-03 15:11, Matthias Pleh wrote:
 On 2011-04-03 23:48, spir wrote:
 (Meaning a standard GUI-programming interface for D.)

Yes, exactly! Just a really small Api to abstract the OS. - Application -> as a representation for the process - Window -> create, show, hide - Canvas/Image -> to draw on + No buttons/textbox or other widgets, this would be part of the higher level (some GUI's on this basic API could use native controls / others may draw it itself / or draw it with GPU ... I mean, there were several attempts to create a GUI, each with a different approach, and most of them are unfinished and abandoned. This could be a base for all GUI's > A fairly big project, I guess! (even for a toy...) It haven't to be complete. Just a start, with the most important corner cases.

I do _not_ think that generic GUI layer is a good idea. GUI toolkits all act very differently about a lot of things. Abstracting them is not easy and tends to result in you losing a lot of their power. It's better to just use the appropriate GUI toolkit and be done with it. Only a _very_ simple GUI application would ultimately be very well served by a generic GUI layer. Not to mention, that's just adding yet _another_ layer of abstraction on top of who knows how many layers of abstraction, and D is supposed to be a _systems_ programming language. Extra layers of abstraction generally harm efficiency, and in this case, they don't really help the programmer all that much in writing their application anyway. You just can't abstract diverse GUI toolkits in an efficient or particularly useful manner. Only the really simplistic stuff would work. What we need is for projects such as qtd to get the proper support that they need to make progress and be completed. - Jonathan M Davis
Apr 03 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 04/04/2011 12:11 AM, Matthias Pleh wrote:
 On 2011-04-03 23:48, spir wrote:
 (Meaning a standard GUI-programming interface for D.)

Yes, exactly! Just a really small Api to abstract the OS.

... and the actual GUI framework, I guess?
 - Application -> as a representation for the process
 - Window -> create, show, hide
 - Canvas/Image -> to draw on
 + No buttons/textbox or other widgets, this would be part of the higher level
 (some GUI's on this basic API could use native controls / others may draw it
 itself / or draw it with GPU ...

 I mean, there were several attempts to create a GUI, each with a different
 approach, and most of them are unfinished and abandoned.
 This could be a base for all GUI's

Hum, I think you'd need to go much further for the API to be of any use. Defining the notions of widget, event & callback, read-only (label) vs read/write (textbox), parent <--> child(ren) relation, styling & style cascade, many more... all of this as a coherent system. Also, like in many other cases, simplicity of use/interface may hide much complication & magic in the background (think Python). But this may be a fairly motivating project.
  A fairly big project, I guess! (even for a toy...)

It haven't to be complete. Just a start, with the most important corner cases.

That would be very cool. Actually, both projects could help & design each other (just like in the case of the standard DB API project). Denis -- _________________ vita es estrany spir.wikidot.com
Apr 03 2011
prev sibling next sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
Andrei Alexandrescu wrote:
 On 4/3/11 5:06 PM, Jens Mueller wrote:
Andrei Alexandrescu wrote:
1. Both seem to be quite fresh on D, so they'll need close coaching
at least in the beginning.

2. Both students seem unfamiliar with the STL, which is a difficult
skill to acquire in a short time frame and is quite recommended for
working on D's containers.

Both valid points. I'd like to help. But how do I know that I'm familiar with the STL? It's containers and generic algorithms glued together via iterators. I've read Effective STL and used the STL but I have never looked at an implementation of the STL. On rare occasions I dived into GNU STL to figure out what was going on.

That would be "STL internals". If you've used the STL systematically then it can be assumed you're familiar with it.

I see. I hope I've been using it in an appropriate manner. I find it sometimes difficult. Getting the functors to work etc.
Regarding the former: They should start reading your book, if they
haven't. What do you mean by coaching? Looking at their code and giving
feedback?

More than that: guiding the next step. That would entail understanding the high level issues quite well.

Unfortunately I think I don't overlook the high level issues. Maybe it's something obvious but right now I feel baffled. I should reread what you have said about the intended container design in previous posts.
With an expanded containers project we could (assuming all goes
smooth) benefit of a host of solid containers by fall. The thing is
that would definitely require very intensive mentoring. I'd probably
be a mentor, and I'd need at least one to be comfortable about
putting this option on the table.

Can you express intensive monitoring in hours per week from your experience?

I don't have experience as a GSoC mentor, but I assume it should be doable in addition to a normal job. The main challenge is having the background.

I agree. It's the background that matters most here. Jens
Apr 04 2011
prev sibling next sibling parent reply Ishan Thilina <ishanthilina gmail.com> writes:
Here's how I think we can solve the problem of overlapping projects:

1. One way is to convince one of the students to work on a different
topic that would also play into his strengths and is of interest to him.
Any suggestions are welcome, both from the students and the community.

After all the time and energy that I have sacrificed for this project it's really sad to let go of this project. But if I get an idea I'll definitely post it here :)
2. Another approach would be to expand the scope of the project. There
are plenty of interesting containers out there (see e.g.
http://stackoverflow.com/questions/500607/what-are-the-lesser-known-but-cool-data-structures)
that are darn useful. I suggest students to look over those and answer
if they'd fell comfortable about implementing e.g. a Bloom filter or a trie.

I looked at few things( such as Skip list, Binary decision tree, Trie, rope) that was listed in that page. Yes, things such as Skip list and Binary decision tree looks interesting. But to be honest I have never heard about those data structures before. So how can I guarantee and point out to a data structure and say that I will be able to implement this before the end of GSoC ? I may be only able to implement only two or three data structures before the time ends? It's very hard to predict on things that you don't know of. I think learning about these data structures won't be a problem. As there was a link for a video tutorial for skip list on that page We'll be able to find more and more resources if we try hard enough( MIT provides lot's videos and we should be able to find good tutorials). But it'll take some time to learn about them. So I really can't give a guarantee in the project proposal( if I was asked to implement these data structures) that I'll be able to implement this much of data structures. This is solely my idea, Christian may have a different idea :)
Apr 05 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Ishan Thilina:

 I looked at few things( such as Skip list, Binary decision tree, Trie, rope)
that
 was listed in that page. Yes, things such as Skip list and Binary decision tree
 looks interesting. But to be honest I have never heard about those data
structures
 before.

Some data structures useful for Phobos: - a graph; - a hash set; - A deque made with a dynamic array of fixed sized arrays; - a Union-Find (not too much hard); - a Bloom filter (easy with the already present bit arrays); - a dawg; - a simple trie; - a BK-tree; - a bidirectional associative array; - a parallelizable immutable finger tree. Bye, bearophile
Apr 05 2011
parent KennyTM~ <kennytm gmail.com> writes:
On Apr 5, 11 17:48, bearophile wrote:
 Ishan Thilina:

 I looked at few things( such as Skip list, Binary decision tree, Trie, rope)
that
 was listed in that page. Yes, things such as Skip list and Binary decision tree
 looks interesting. But to be honest I have never heard about those data
structures
 before.

Some data structures useful for Phobos: - a graph; - a hash set; - A deque made with a dynamic array of fixed sized arrays; - a Union-Find (not too much hard); - a Bloom filter (easy with the already present bit arrays); - a dawg; - a simple trie; - a BK-tree; - a bidirectional associative array; - a parallelizable immutable finger tree. Bye, bearophile

From this list, I'd only want to see 'hash set', 'deque', 'bidirectional AA' and maybe 'trie' in std.container. Union-Find - Maybe useful, but when did you need a union-find structure outside of Kruskal's algorithm? Bloom filter - I've never hit a case where a hash set is too big and a bloom filter is enough. Dawg, BK-tree, finger tree - What are these? Why are they useful for Phobos? Graph - Yes it is useful, but there are too many operations associated with it, which should better live as its own module (std.container.graph?). P.S. Here I'm talking about future addition to std.container in general, not about the two GSoC projects. P.P.S. if you don't mind I'd like to add 'interval set' to the list. See Boost.Icl.
Apr 05 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 04/05/2011 11:48 AM, bearophile wrote:
 Ishan Thilina:

 I looked at few things( such as Skip list, Binary decision tree, Trie, rope)
that
 was listed in that page. Yes, things such as Skip list and Binary decision tree
 looks interesting. But to be honest I have never heard about those data
structures
 before.

Some data structures useful for Phobos: - a graph; - a hash set; - A deque made with a dynamic array of fixed sized arrays; - a Union-Find (not too much hard); - a Bloom filter (easy with the already present bit arrays); - a dawg; - a simple trie; - a BK-tree; - a bidirectional associative array; - a parallelizable immutable finger tree.

Do you really find it appropriate to throw an avalanche of new data structure over Ishan when he just said he has "never heard about" "Skip list, Binary decision tree, Trie, rope"? Denis -- _________________ vita es estrany spir.wikidot.com
Apr 05 2011
prev sibling parent Jonas Drewsen <jdrewsen nospam.com> writes:
On 03/04/11 21.05, Andrei Alexandrescu wrote:
 We are honored to receive a fair amount of interest from students at our
 GSoC 2011.

 One issue is that at least one student (who contacted me off-list)
 couldn't find a project to work on that would best play into his
 strengths. I think it's not too late to improve our GSoC ideas page
 (http://prowiki.org/wiki4d/wiki.cgi?GSOC_2011_Ideas).

* Web development framework - e.g. inspired by Ruby on Rails.
Apr 05 2011