Re: GTKD resources
Here is what I came up with
import gdkpixbuf.Pixbuf;
GdkPixbuf*[string] __ImageCache;
void SetImage(string imgName)(gtk.Image T)
{
import std.path, std.conv, gdkpixbuf.Pixbuf;
GError* err = null;
if (imgName !in __ImageCache)
{
GdkPixbufLoader* __PixbufLoader;
writeln("Image not cached, caching: "~imgName);
enum imgData = cast(ubyte[])(import(baseName(imgName)).ptr);
if (__PixbufLoader == null)
__PixbufLoader = gdk_pixbuf_loader_new();
assert(__PixbufLoader, "Error: Cannot create pixbuf loader!");
if (!gdk_pixbuf_loader_write(__PixbufLoader,
cast(char*)imgData.ptr, imgData.length, ))
assert(__PixbufLoader, "Error: Cannot load pixbuf
loader!");
if (!gdk_pixbuf_loader_close(__PixbufLoader, ))
assert(__PixbufLoader, "Error: Cannot create pixbuf!");
auto pixbuf = gdk_pixbuf_loader_get_pixbuf(__PixbufLoader);
if (pixbuf == null)
assert("Error: Cannot load pixbuf!");
__ImageCache[imgName] = pixbuf;
}
import gtk.c.functions;
gtk_image_set_from_pixbuf(T.getImageStruct(),
__ImageCache[imgName]);
}
Maybe that will help someone. Not sure if it is the best way but
seems to work.
Re: Persistent Storage
On Saturday, 12 August 2017 at 01:16:35 UTC, HyperParrow wrote: On Friday, 11 August 2017 at 22:21:53 UTC, Mr. Pib wrote: [...] Try a serialization library or inifiled. Some may even use a DB with ORM for this. https://code.dlang.org/packages/inifiled https://code.dlang.org/packages/jsonizer https://code.dlang.org/packages/asdf https://code.dlang.org/packages/yamlserialized etc... there are much. Thanks, I wrote my own quick version for what I need so I'll probably use that for now. In the future I might look in to those.
Re: Bug in D?!
On Friday, 11 August 2017 at 23:34:04 UTC, Adam D. Ruppe wrote: On Friday, 11 August 2017 at 22:43:02 UTC, Mr. Pib wrote: int and I should be able to append an int without having to worry about the value of the int. Appending an int to a string really ought to just be a type mismatch error. We might be able to convince the leadership to do that too, since that still fits with the C compatibility guidelines. I'd prefer that since at least it wouldn't silently work and produce potentially catastrophic errors. But then that too is still breaking backwards compatibility(which I think is the plague of the 21st century).
Re: Bug in D?!
On Friday, 11 August 2017 at 22:50:53 UTC, ketmar wrote: Mr. Pib wrote: Wow, that is pretty screwed up! I thought D was against implicit conversions that might cause problems? I'm passing an int and I should be able to append an int without having to worry about the value of the int. Instead D chose to do something very strange, awkward, and error prone. this is legacy we got from trying to be C-compatible (along with int/uint autoconversion, and some other things). i believe that initially it was done to allow something like `char c = 32;`, and now it is too late to change it, 'cause such change will break existing code (and we're trying to not break the code without a *very* strong reason, even if keeping old code working means keeping some old quirks). The problem is that that mentality perpetuates the problem. It keeps things from ever getting fixed and corrected by it's very nature... all to supposedly save time but how much time does it waste too? It would be better to break things cleanly and let those that get errors fix them... cause hell, after some years the old code will not be used more anyways or be rewritten so maybe it is trying to solve a problem that doesn't actually exist?
Re: Bug in D?!
On Friday, 11 August 2017 at 04:17:32 UTC, ketmar wrote:
Mr. Pib wrote:
string Q(alias T, alias D)()
{
pragma(msg, T);
pragma(msg, D);
enum x = T~" = "~D~";";
pragma(msg, x);
}
mixin(Q!(`x`, 100)());
outputs, at compile time,
x
100
x = d;
there is no lowercase d. I did initially define Q as
string Q(alias T, D)(D d)
and one might think it is remnants left over from I cleaned
the project so it shouldn't be happening. Seems like a bug.
(I realized that I'd probably only ever pass compile time
values)
Of course, using D.stringof gives the value.
The problem is the case of D.
nope. the problem is the *value* of D. `char(100)` == 'd'.
string s = "<"~100~">";
yes, this works. weither this bug or not is questionable, but
this is how D works regerding to implicit type conversions:
small ints (in the range of [0..char.max]) will be implicitly
converted to `char` if necessary.
Wow, that is pretty screwed up! I thought D was against implicit
conversions that might cause problems? I'm passing an int and I
should be able to append an int without having to worry about the
value of the int. Instead D chose to do something very strange,
awkward, and error prone.
Persistent Storage
Does D have a persistent storage somewhere? I'd like something easy to use that allows me to load and save settings to disk in between executions of the program. I want to specify the variable to be saved or loaded and a default value. e.g., Persist_Load(Some_variable, 100); will load Some_variable from disk. If the storage does not exist on disk it will use the value 100. It should manage the variables internally so it knows what is what. I don't mind actually specifying some_variable as a string to do this or using mixins and templates to achieve this, but it should be a one liner thing.
Bug in D?!
string Q(alias T, alias D)()
{
pragma(msg, T);
pragma(msg, D);
enum x = T~" = "~D~";";
pragma(msg, x);
}
mixin(Q!(`x`, 100)());
outputs, at compile time,
x
100
x = d;
there is no lowercase d. I did initially define Q as
string Q(alias T, D)(D d)
and one might think it is remnants left over from I cleaned the
project so it shouldn't be happening. Seems like a bug.
(I realized that I'd probably only ever pass compile time values)
Of course, using D.stringof gives the value.
The problem is the case of D.
Re: GTKD resources
On Friday, 11 August 2017 at 02:27:21 UTC, captaindet wrote:
On 2017-08-11 13:00, Mr. Pib wrote:
How can one include external files such as glade, icons,
images that are
static in nature in to the binary but not require extraction
on program
run to be used?
gtk's builder doesn't seem to take an in memory representation
of glade
files and building a pixbuf seems quite over the top to do
such simple
things?
including the glade UI/XML defs to the executable is simple,
compile with -J. switch and:
immutable string UIdefs = import("myuidefs.glade");
...
main(){
...
builder.addFromString( UIdefs );
...
Thanks. It one can use pixbuf to do something similar, albeit
more complicated.
https://stackoverflow.com/questions/14121166/gdk-pixbuf-load-image-from-memory
GTKD resources
How can one include external files such as glade, icons, images that are static in nature in to the binary but not require extraction on program run to be used? gtk's builder doesn't seem to take an in memory representation of glade files and building a pixbuf seems quite over the top to do such simple things?
