Skip to content

Create empty DGui skeleton project #518

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Create empty DGui skeleton project #518

wants to merge 1 commit into from

Conversation

andre2007
Copy link
Contributor

A minimal DGui application skeleton can be built

@Geod24
Copy link
Member

Geod24 commented Feb 23, 2015

I really think we should have a "plugin" system for that. It would mostly work by convention, so that for example, dub init vibe.d will look for dub-init folder (or subpackage) in vibe.d package, and copy it. That would also fix the issues of the packages not being in sync).

@s-ludwig
Copy link
Member

See also my reply in #453.

@etcimon
Copy link
Contributor

etcimon commented Feb 23, 2015

I really think we should have a "plugin" system for that. It would mostly work by convention, so that for example, dub init vibe.d

A true plugin system would automatically search for and run shared libraries, and identify a set of callbacks, related or not to init files. This would be useful for eg. adding custom pre-processors, like a diet templates compiler that isn't CTFE but runs at compile-time.

@s-ludwig
Copy link
Member

There are many flavors of plugin systems, it doesn't always have to be shared library based. In this particular case I think that a template package is really a much better solution. But yeah, a "build" plugin system like you describe is also something that we need to think about. I've recently talked about such possibilities with Atila Neves via e-mail and could post those in a separate ticket or on the forums.

@MartinNowak
Copy link
Member

See also my reply in #453.

#453 (comment)

@blm768
Copy link

blm768 commented Dec 17, 2015

Isn't this basically a subset of the features in #600?

@s-ludwig
Copy link
Member

@blm768: Yes, I think we should actually close this and go for a variant of #600 instead (using a sub package instead of a specific sub path).

@s-ludwig s-ludwig closed this Dec 17, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants