Resources are chunks of binary or textual data resides in the body of
executable file. Code of executable
can get a read only access to them - similar to access to staticly
initialized constants/variables.

I think that D should have a unified (cross-platform) way to deal with
resources.
As an one possible idea could be to use special version of 'import' keyword
with notation similar to cast()

//example

ubyte[] TopCornerPng = import(myproject.res.images.filename.png);
char[] MainStyleCss = import(myproject.res.layout.style.css);
char[] MainLayout = import(myproject.res.layout.style.htm);

// another one

Object[char[]] res;
gRes["logo"] = import(myproject.res.images.logo.png);
gRes["icon"] = import(myproject.res.images.icon.ico);
gRes["small-icon"] = import(myproject.res.images.smallicon.ico);
gRes["about-text"] = cast(char[]) import(myproject.res.about.txt);

Any comments or other ideas?

I like the idea, but I think it's better to implement a std.res.loadResource
function rather than to change the D grammar.


Andrew Fedoniouk wrote:
> Resources are chunks of binary or textual data resides in the body of executable file. Code of executable
> can get a read only access to them - similar to access to staticly initialized constants/variables.
> 
> I think that D should have a unified (cross-platform) way to deal with resources.
> As an one possible idea could be to use special version of 'import' keyword with notation similar to cast()
> 
> //example
> 
> ubyte[] TopCornerPng = import(myproject.res.images.filename.png);
> char[] MainStyleCss = import(myproject.res.layout.style.css);
> char[] MainLayout = import(myproject.res.layout.style.htm);
> 
> // another one
> 
> Object[char[]] res;
> gRes["logo"] = import(myproject.res.images.logo.png);
> gRes["icon"] = import(myproject.res.images.icon.ico);
> gRes["small-icon"] = import(myproject.res.images.smallicon.ico);
> gRes["about-text"] = cast(char[]) import(myproject.res.about.txt);
> 
> Any comments or other ideas?
> 
> 
> 
> 
> 
> 
> 
> 
> 

>I like the idea, but I think it's better to implement a std.res.loadResource
> function rather than to change the D grammar.
>
Just one question: from where will [std.res.]loadResource ? On Win32 and on Linux?

It is possible to do now following:

ubyte[1020] myRes = [
  0xFD, 0xFA, 0xBC, .....
];

but it is not so convenient  - same chunks of information stored in two places

There are probably more options similar to D code embedded inside HTML. Hmm... Seems like too wild idea...

Andrew Fedoniouk wrote:

> Resources are chunks of binary or textual data resides in the body of executable file. Code of executable
> can get a read only access to them - similar to access to staticly initialized constants/variables.

As a side note, resources on Mac OS X are stored in a sub-directory...

Program.app/
    Contents/
        MacOS/
            Program (<-- this is the executable)
        Resources/
            Program.rsrc (<-- these are resources)
            English.lproj/
                 Localized.rsrc	
            sv.lproj/
                 Localized.rsrc	

Having a loadResource function would still work fine here too, though.

--anders

Hello !

I come back again with my plugin idea. (yes I really like it, please go to the thread for more informations)

Let create a "ressource" plugin that takes any binary file and convert it into an array of char: char[size] stuff = 0x784, 0x765, 0x.... etc


Then We write:

pragma(plugin,ressource) {
	image = ../images/im.png
        text  = ../text/text.txt
}

Or something similar.
Now we can use the variables image and text.
Easy and convinient.

G.VIDAL







Le Sat, 05 Mar 2005 18:42:04 -0800, Andrew Fedoniouk a écrit :

> Resources are chunks of binary or textual data resides in the body of
> executable file. Code of executable
> can get a read only access to them - similar to access to staticly
> initialized constants/variables.
> 
> I think that D should have a unified (cross-platform) way to deal with
> resources.
> As an one possible idea could be to use special version of 'import' keyword
> with notation similar to cast()
> 
> //example
> 
> ubyte[] TopCornerPng = import(myproject.res.images.filename.png);
> char[] MainStyleCss = import(myproject.res.layout.style.css);
> char[] MainLayout = import(myproject.res.layout.style.htm);
> 
> // another one
> 
> Object[char[]] res;
> gRes["logo"] = import(myproject.res.images.logo.png);
> gRes["icon"] = import(myproject.res.images.icon.ico);
> gRes["small-icon"] = import(myproject.res.images.smallicon.ico);
> gRes["about-text"] = cast(char[]) import(myproject.res.about.txt);
> 
> Any comments or other ideas?

In article <d0dqov$1v7f$1@digitaldaemon.com>, Andrew Fedoniouk says...
>
>Resources are chunks of binary or textual data resides in the body of
>executable file. Code of executable
>can get a read only access to them - similar to access to staticly
>initialized constants/variables.
>
>I think that D should have a unified (cross-platform) way to deal with
>resources.
>As an one possible idea could be to use special version of 'import' keyword
>with notation similar to cast()
>
>//example
>
>ubyte[] TopCornerPng = import(myproject.res.images.filename.png);
>char[] MainStyleCss = import(myproject.res.layout.style.css);
>char[] MainLayout = import(myproject.res.layout.style.htm);
>
>// another one
>
>Object[char[]] res;
>gRes["logo"] = import(myproject.res.images.logo.png);
>gRes["icon"] = import(myproject.res.images.icon.ico);
>gRes["small-icon"] = import(myproject.res.images.smallicon.ico);
>gRes["about-text"] = cast(char[]) import(myproject.res.about.txt);
>
>Any comments or other ideas?

Resources are usually pretty platform-specific so MinWin only handles string (for i18n) and image resources. Resources are looked up by string key. Strings are loaded using a method of the Application object. Since images in MinWin are device-dependent images are loaded using a method on the GContext object (HDC/GC/GdkGC).

Are there problem with such a system that your proposal would fix? I don't see why having functions load data is a problem. Multiple functions also let you avoid cast(char[]).

-Ben

>> Resources are chunks of binary or textual data resides in the body of
>> executable file. Code of executable
>> can get a read only access to them - similar to access to staticly
>> initialized constants/variables.
>
> As a side note, resources on Mac OS X are stored in a sub-directory...
>
> Program.app/
>     Contents/
>         MacOS/
>             Program (<-- this is the executable)
>         Resources/
>             Program.rsrc (<-- these are resources)
>             English.lproj/
>                  Localized.rsrc sv.lproj/
>                  Localized.rsrc
> Having a loadResource function would still work fine here too, though.
>
> --anders

Anders, I think you've missed my point:
chunks of binary or textual data resides in *the body executable file*

Having "resources" as separate files introduces some problems. When you have simple GUI app and resources inside you don't need any unstallation - just copy-n-run.

GUI apps use not only strings but also icons and html and other "graphical" data. It make sense to bind them into exe as they are parts of such exe as code, data and "resource" sections.

Yep, this pretty much the same idea.
But mine is simpler from 1) implementation point of view and
2) allows to define comples structures like:

struct ToolbarImgDef
{
   int         iconWidth;
   int         iconHeight;
   ubyte[]  png;
 }

static ToolbarImgDef mainTbDef = { 16, 15, import(mytoolbar.png)  }
Toolbar mainTb = new Toolbar(mainTbDef);

Idea of plugins is good in fact. But for most cases it would be
enough to implement something extremely simple as import(mytoolbar.png)

Andrew.






"G.Vidal" <gyvidal@wanadoo.fr> wrote in message news:pan.2005.03.06.09.38.53.693865@wanadoo.fr...
>
> Hello !
>
> I come back again with my plugin idea. (yes I really like it, please go to the thread for more informations)
>
> Let create a "ressource" plugin that takes any binary file and convert it into an array of char: char[size] stuff = 0x784, 0x765, 0x.... etc
>
>
> Then We write:
>
> pragma(plugin,ressource) {
> image = ../images/im.png
>        text  = ../text/text.txt
> }
>
> Or something similar.
> Now we can use the variables image and text.
> Easy and convinient.
>
> G.VIDAL
>
>
>
>
>
>
>
> Le Sat, 05 Mar 2005 18:42:04 -0800, Andrew Fedoniouk a écrit :
>
>> Resources are chunks of binary or textual data resides in the body of
>> executable file. Code of executable
>> can get a read only access to them - similar to access to staticly
>> initialized constants/variables.
>>
>> I think that D should have a unified (cross-platform) way to deal with
>> resources.
>> As an one possible idea could be to use special version of 'import'
>> keyword
>> with notation similar to cast()
>>
>> //example
>>
>> ubyte[] TopCornerPng = import(myproject.res.images.filename.png);
>> char[] MainStyleCss = import(myproject.res.layout.style.css);
>> char[] MainLayout = import(myproject.res.layout.style.htm);
>>
>> // another one
>>
>> Object[char[]] res;
>> gRes["logo"] = import(myproject.res.images.logo.png);
>> gRes["icon"] = import(myproject.res.images.icon.ico);
>> gRes["small-icon"] = import(myproject.res.images.smallicon.ico);
>> gRes["about-text"] = cast(char[]) import(myproject.res.about.txt);
>>
>> Any comments or other ideas?
> 

Pwet Pwet Pwet....

pragma(plugin,ressource) { im = mytoolbar.png }
static ToolbarImgDef mainTbDef = { 16, 15, im }

Not so bad too ! and we don't need to add another import keyword in the D grammar set.

> Resources are usually pretty platform-specific so MinWin only handles
> string
> (for i18n) and image resources. Resources are looked up by string key.
> Strings
> are loaded using a method of the Application object. Since images in
> MinWin are
> device-dependent images are loaded using a method on the GContext object
> (HDC/GC/GdkGC).
>
> Are there problem with such a system that your proposal would fix? I don't
> see
> why having functions load data is a problem. Multiple functions also let
> you
> avoid cast(char[]).
>

"Resources are usually pretty platform-specific..."

Yes, sometimes.

But let's take a closer look:

Strings are the same.
Text and its various forms - html, css, etc. also the same.
Images could be also unified - e.g. ppm data (24bpp and 32bpp) could be
mapped into win32::DIB section one-to-one.
For gif, png and jpg I am going to create "standard".lib module for D which
will include gif/png/jpg loading/saving.

My J-SMILE demo uses following structure of EXE:
It is a bundle of concatenated items - EXE file by itself :

j-smile-vm.exe,
"classname1" classname2.class
"classname2" classname2.class
"imagefile1" imagefile1.png
"htmlfile1" htmlfile1.htm
Loading of resources is a part of builtin ClassLoader. Very convenient.

If we will have import(filename) in D it will extend concept even further:
resource
definitions can be organized in structures and arrays and addresed very
effectively.