Re: Dgame RC #1
On Friday, 3 April 2015 at 04:55:42 UTC, Mike Parker wrote: succeed. You can look at the functions allowSDL_2_0_0 and allowSDL_2_0_1 in sdl.d [1] to see exactly which functions were added in 2.0.1 and 2.0.2 so that you can determine if you Gah! I always forget to add the referenced links. [1] https://github.com/DerelictOrg/DerelictSDL2/blob/SDL-2.0.x/source/derelict/sdl2/sdl.d#L534
Re: Dgame RC #1
On Thursday, 2 April 2015 at 09:38:05 UTC, Namespace wrote: Dgame is based on SDL 2.0.3 (as described in the installation tutorial), but tries to "wrap" any function call which is introduced after SDL 2.0.0: static if (SDL_VERSION_ATLEAST(2, 0, 2)) so that Dgame should be usable with any SDL2.x version. I will investigate which function is calling SDL_HasAVX. None of that matters. This has nothing to do with what Dgame is calling, but what Derelict is actually trying to load. SDL_HasAVX was added to the API in 2.0.2 so does not exist in previous versions of SDL, therefore an exception will be thrown when Derelict tries to load older versions and that function is missing. Dgame will load DerelictSDL2 as usual and then it will check if the supported version is below 2.0.2. If so, DerelictSDL2 will be reloaded with SharedLibVersion(MAX_SUPPORTED_VERSION)). That should that work, right? No, it won't. By default, Derelict attempts to load functions from the 2.0.2 API (which includes 2.0.3, since the API did not change). That means anything below 2.0.2 will *always* fail to load because they are missing the functions added to the API in 2.0.2. The right way to do this is to use the selective loading mechanism to disable exceptions for certain functions. With the 1.9.x versions of DerelictSDL2, you no longer have to implement that manually. As I wrote above, you can do this: DerelictSDL2.load(SharedLibVersion(2,0,0)); With that, you can load any version of SDL2 available on the system, from 2.0.0 on up. It uses selective loading internally. For example, 2.0.0 will load even though it is missing SDL_HasAVX and several other functions added in 2.0.1 and 2.0.2. But you should only do this if you are absolutely sure that you are not calling any functions that were not present in 2.0.0. For example, the SDL_GetPrefPath/SDL_GetBasePath functions were added in 2.0.1. If you require those and need nothing from 2.0.2, then you should do this: DerelictSDL2.load(SharedLibVersion(2,0,1)); Now, 2.0.0 will fail to load, but 2.0.1 and higher will succeed. You can look at the functions allowSDL_2_0_0 and allowSDL_2_0_1 in sdl.d [1] to see exactly which functions were added in 2.0.1 and 2.0.2 so that you can determine if you require any of them. I also encourage you to go and do a diff of the SDL headers for each release to see things other than functions, like new constants, that were added in each release (and to protect against the possibility that I've made a mistake somewhere). That won't affect whether or not Derleict loads, but a new constant added in SDL 2.0.2 won't work with a function that existed in 2.0.0, for example.
Re: Dgame RC #1
On Thursday, 2 April 2015 at 18:49:15 UTC, Namespace wrote: The master branch should now make an automatic downgrade. I am still using rc1 but managed to get everything working. I built SDL(and the other libraries) from source and now everything works great. Thanks for your help. Craig
Re: Loading of widgets from DML markup and DML Editor in DlangUI
On Thursday, 2 April 2015 at 13:40:49 UTC, Vadim Lopatin wrote: Useful feature is added to DlangUI. You can write UI layout as QML-like code, and load it in runtime from file, resource, or just string constant. Great job, Vadim! Thank you!
Re: Dgame RC #1
The master branch should now make an automatic downgrade.
Tagged Scriptlike release: v0.7.0
Scriptlike: A utility library to aid in writing script-like programs in D. https://github.com/Abscissa/scriptlike http://code.dlang.org/packages/scriptlike Two things in this v0.7.0 release: - Easy input-prompting module "scriptlike.interact", by Jesse Phillips. This has actually been in master for quite some time, but now it's part of a tagged release. Docs: http://semitwist.com/scriptlike/interact.html - Fixed: The unittests failed to compile on DMD 2.067.0 Early heads-up warning: While scriptlike currently supports DMDs as early as 2.064.2, I will likely be increasing the minimum supported DMD up to 2.066.0 between now and the next release, due to increasing reliance on the newer parts of std.process (which prior to 2.066.0 had "paths with spaces" problems on Windows, which I was previously able to work around using the outdated system() function).
Re: Loading of widgets from DML markup and DML Editor in DlangUI
On Thu, 02 Apr 2015 14:09:14 +, Vadim Lopatin wrote: > On Thursday, 2 April 2015 at 13:56:05 UTC, ketmar wrote: >> are there any plans to add cassowary solver[1] to DlangUI? i believe i >> seen D port of it (my own is not usable with DMD). >> >> [1] https://constraints.cs.washington.edu/cassowary/ > > How could it be useful for DlangUI? > Some advanced kind of layout? yes, it's universal constraint solver that especially aimed to building GUI layouts. apple adapted it as layout engine for their macos x and ios, for example. signature.asc Description: PGP signature
Re: Loading of widgets from DML markup and DML Editor in DlangUI
On Thursday, 2 April 2015 at 13:56:05 UTC, ketmar wrote: are there any plans to add cassowary solver[1] to DlangUI? i believe i seen D port of it (my own is not usable with DMD). [1] https://constraints.cs.washington.edu/cassowary/ How could it be useful for DlangUI? Some advanced kind of layout?
Re: Loading of widgets from DML markup and DML Editor in DlangUI
are there any plans to add cassowary solver[1] to DlangUI? i believe i seen D port of it (my own is not usable with DMD). [1] https://constraints.cs.washington.edu/cassowary/ signature.asc Description: PGP signature
Loading of widgets from DML markup and DML Editor in DlangUI
Hello,
Useful feature is added to DlangUI.
You can write UI layout as QML-like code, and load it in runtime
from file, resource, or just string constant.
Instead of manual creation of widgets in code, you may write like
this:
==
module app;
import dlangui;
mixin APP_ENTRY_POINT;
/// entry point for dlangui based application
extern (C) int UIAppMain(string[] args) {
// create window
Window window = Platform.instance.createWindow("DlangUI
example - HelloWorld", null);
// create some widget to show in window
window.mainWidget = parseML(q{
VerticalLayout {
margins: 10
padding: 10
backgroundColor: "#C0E0E070" // semitransparent
yellow background
// red bold text with size = 150% of base style
size and font face Arial
TextWidget { text: "Hello World example for
DlangUI"; textColor: "red"; fontSize: 150%; fontWeight: 800;
fontFace: "Arial" }
// arrange controls as form - table with two
columns
TableLayout {
colCount: 2
TextWidget { text: "param 1" }
EditLine { id: edit1; text: "some text" }
TextWidget { text: "param 2" }
EditLine { id: edit2; text: "some text for
param2" }
TextWidget { text: "some radio buttons" }
// arrange some radio buttons vertically
VerticalLayout {
RadioButton { id: rb1; text: "Item 1" }
RadioButton { id: rb2; text: "Item 2" }
RadioButton { id: rb3; text: "Item 3" }
}
TextWidget { text: "and checkboxes" }
// arrange some checkboxes horizontally
HorizontalLayout {
CheckBox { id: cb1; text: "checkbox 1" }
CheckBox { id: cb2; text: "checkbox 2" }
}
}
HorizontalLayout {
Button { id: btnOk; text: "Ok" }
Button { id: btnCancel; text: "Cancel" }
}
}
});
// you can access loaded items by id - e.g. to assign
signal listeners
auto edit1 =
window.mainWidget.childById!EditLine("edit1");
auto edit2 =
window.mainWidget.childById!EditLine("edit2");
// close window on Cancel button click
window.mainWidget.childById!Button("btnCancel").onClickListener =
delegate(Widget w) {
window.close();
return true;
};
// show message box with content of editors
window.mainWidget.childById!Button("btnOk").onClickListener =
delegate(Widget w) {
window.showMessageBox(UIString("Ok button pressed"d),
UIString("Editors
content\nEdit1: "d ~ edit1.text ~ "\nEdit2: "d ~ edit2.text));
return true;
};
// show window
window.show();
// run message loop
return Platform.instance.enterMessageLoop();
}
==
Function parseML loads widgets from code written in DML language.
There is DMLEdit sample app in DlangUI/examples directory.
You can run it with dub:
dub run dlangui:dmledit
It allows to edit QML text and see how it will look like when
loaded into app (F5 refreshes view).
Syntax highlight, bracket matching, go to error and other useful
features are implemented.
TODOs:
* automatic mapping of loaded widgets to member variables (e.g.
by matching of widget id and variable names)
* automatic assignment of signal listeners to member functions,
according to DML or just based on signal name and widget id (e.g.
onButton1Click method may be connected to widget with
id="Button1" signal click )
I hope this enhancement will be useful.
Best regards,
Vadim
Re: Dgame RC #1
On Thursday, 2 April 2015 at 09:30:43 UTC, Namespace wrote: Just a follow up comment. Apparently the instructions for installing all libraries at once in the tutorial don't work for OpenSuse. So I couldn't just install the SDL library but had to install the other libraries individually: So just in case there are any other OpenSuse users out there (note, I suppose I didn't need the devel version of libSDL2 ...): sudo zypper in libSDL2-devel sudo zypper in libSDL2_image-2_0-0 sudo zypper in libSDL2_mixer-2_0-0 sudo zypper in libSDL2_ttf-2_0-0 I will add this to the installation tutorial. Unfortunately I did not tested Dgame with OpenSUSE, sorry for your trouble. No worries, you can't test everything, and OpenSUSE isn't as popular as some other distros. Also, I guess OpenSUSE isn't going to work with default libs anyway because of the versions. I am going to build SDL from scratch and install. I've downloaded 2.0.3, so I should be good to go. Thanks Namespace and Mike for your help.
Re: Dgame RC #1
I'll fix this as follows: Dgame will load DerelictSDL2 as usual and then it will check if the supported version is below 2.0.2. If so, DerelictSDL2 will be reloaded with SharedLibVersion(MAX_SUPPORTED_VERSION)). That should that work, right?
Re: Dgame RC #1
On Thursday, 2 April 2015 at 07:56:19 UTC, Mike Parker wrote: On 4/2/2015 11:36 AM, Craig Dillabaugh wrote: derelict.util.exception.SymbolLoadException@../../../.dub/packages/derelict-util-1.9.1/source/derelict/util/exception.d(35): Failed to load symbol SDL_HasAVX from shared library libSDL2.so This error message is telling you two things. First, SDL is installed on your system and the loader found it just fine. Second, the loader was unable to find the SDL_HasAVX function in libSDL2.so. SDL_HasAVX was added to the API in SDL 2.0.2, so you have an older version installed on your system and DGame is attempting to load a more recent version. Derelict will load either SDL 2.0.2 or 2.0.3. The latter is the latest release, but there are no API differences between them. From your end, the solution is to install the latest version of SDL2. Another solution is for DGame to take advantage of the SharedLibVersion feature of Derelict to set a minimum acceptable version of SDL. For example, if DGame doesn't use any API features added to SDL since 2.0.0, then this will allow any version of SDL2 to load: DerelictSDL2.load(SharedLibVersion(2,0,0)); Bye bye SymbolLoadException. Then again, loading the older versions makes it possible for DGame to be affected by SDL bugs that have since been fixed, so I make no judgement on whether or not it's worth it. Dgame is based on SDL 2.0.3 (as described in the installation tutorial), but tries to "wrap" any function call which is introduced after SDL 2.0.0: static if (SDL_VERSION_ATLEAST(2, 0, 2)) so that Dgame should be usable with any SDL2.x version. I will investigate which function is calling SDL_HasAVX.
Re: Dgame RC #1
Just a follow up comment. Apparently the instructions for installing all libraries at once in the tutorial don't work for OpenSuse. So I couldn't just install the SDL library but had to install the other libraries individually: So just in case there are any other OpenSuse users out there (note, I suppose I didn't need the devel version of libSDL2 ...): sudo zypper in libSDL2-devel sudo zypper in libSDL2_image-2_0-0 sudo zypper in libSDL2_mixer-2_0-0 sudo zypper in libSDL2_ttf-2_0-0 I will add this to the installation tutorial. Unfortunately I did not tested Dgame with OpenSUSE, sorry for your trouble.
Re: Dgame RC #1
On 4/2/2015 4:56 PM, Mike Parker wrote: Derelict will load either SDL 2.0.2 or 2.0.3... ...by default.
Re: Dgame RC #1
On 4/2/2015 11:36 AM, Craig Dillabaugh wrote: derelict.util.exception.SymbolLoadException@../../../.dub/packages/derelict-util-1.9.1/source/derelict/util/exception.d(35): Failed to load symbol SDL_HasAVX from shared library libSDL2.so This error message is telling you two things. First, SDL is installed on your system and the loader found it just fine. Second, the loader was unable to find the SDL_HasAVX function in libSDL2.so. SDL_HasAVX was added to the API in SDL 2.0.2, so you have an older version installed on your system and DGame is attempting to load a more recent version. Derelict will load either SDL 2.0.2 or 2.0.3. The latter is the latest release, but there are no API differences between them. From your end, the solution is to install the latest version of SDL2. Another solution is for DGame to take advantage of the SharedLibVersion feature of Derelict to set a minimum acceptable version of SDL. For example, if DGame doesn't use any API features added to SDL since 2.0.0, then this will allow any version of SDL2 to load: DerelictSDL2.load(SharedLibVersion(2,0,0)); Bye bye SymbolLoadException. Then again, loading the older versions makes it possible for DGame to be affected by SDL bugs that have since been fixed, so I make no judgement on whether or not it's worth it.
