On Mon, 20 May 2013 20:46:48 -0700, Tyler Jameson Little
<beatgam...@gmail.com> wrote:
I'd love to get this up and running but I think we've got a blocker
right now in D and that is the lack of package import,
the GUI system is
going to be a monster no matter how it's sliced and I'd lack to avoid
the std.datetime effect. Sorry Jonathan Davis!
Why do you need package import? Can't you achieve the equivalent by
having one module that imports all the others publicly leaving the
application programmer only one module to import?
I also agree. But a package import is in the works apparently, so by the
time something is ready to show, the feature will be there. Just shim
for now (with an all.d or whatever) and get stuff done. I think we're
looking at a 1yr or so investment before trying to include in Phobos
becomes a consideration.
Once we get package import into D we can start building out the basics.
Do you have any experience with concurrent hashmaps by chance?
No. Why do you want concurrency? Aren't associative arrays hashmaps?
My only experience with hashing techniques (other than as an end user
of classes/functions/features using them) was implementing git binary
patches in Python for use in one of my GUIs.
I agree. UIs are asynchronous by nature, not concurrent. If we agree on
this premise, basic associative arrays can be used, and all access to
them can be guarded by a simple mutex.
See my DConf talk in a few days (I was #3 on Day 2). It has a pattern for
concurrent data mutation at the end that might be more useful than a
global lock, which has some pretty disturbing implications for
high-performance rendering code.
I'm completely willing to head up the initial development. I probably
won't get anything done, and any initial work will be Linux-specific (I
honestly don't care about Mac OS X or Windows). If anything does get
done, I'll definitely come back here to get help on the design. I'm
willing to do some leg-work, but I'm not experienced in any way, shape
or form with GUI development (most of my work is server-type stuff in Go
or front-end stuff in JS/HTML5/CSS3).
As far as rendering goes I was think about designing something pluggable,
so it would have to follow a defined interface. It might be good to at
least sketch out what that interface needs. It should be as simple as
possible, basically just the primitives and anything needed to accurately
render the visual tree.
If we're generally in agreement that a UI toolkit is a good direction,
I'd love to waste the next few months of my life doing something that
likely won't go anywhere. I personally think it's much more exciting to
make something in native D instead of trying to work around the lack of
concern other C++ toolkits like Qt have for cross-language portability.
I can't tell if this is snark or not so I'll assume it isn't. :-) I don't
know how likely cross-language portability is to be achieved by any UI
toolkit, way to many things that need more advanced language features. If
we use D we'd probably end-up using a non-portable set of language
features anyways...
It'd be nice, but given how constraining C++ is compared to D it might not
be practical in the long run. Although the rendering interface might be
able to plug with D. That should be simple enough...
--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
