And one more, Anders:

Let's say application A uses two libraries GUI-component-B and GUI-component-C

These two have its own resources (e.g. images) so maintaining
the following:

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

is a problem. I mean distribution and dependencies management.

Andrew Fedoniouk wrote:

> 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.

Mac OS X handles bundles (which are just "special" directories)
in the same manner that it does files. So you just drag .apps...

> 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.

The ".rsrc" listed was just a blanket term for heaps of such files.
See http://developer.apple.com/documentation/ for loads of docs...

> And one more, Anders:
> 
> Let's say application A uses two libraries GUI-component-B and
> GUI-component-C

These two would be "Frameworks", under Mac OS X. These entities
can contain both libraries, headers and also resource files...

> These two have its own resources (e.g. images) so maintaining
> the following:
> 
>>> Program.app/
>>>     Contents/
> 
> is a problem. I mean distribution and dependencies management.

Disk space is cheap, so Mac OS X just makes each application
have one copy of the (indentical) frameworks. Avoids DLL hell.

--anders

>
> Disk space is cheap, so Mac OS X just makes each application have one copy of the (indentical) frameworks. Avoids DLL hell.
>

Probably yes, but for some aesthetical reasons I don't like to have something simple as Calculator.exe as a bunch of files instead of one.

I would like to have it mono exectable just to be able to copy it on e.g. USB drive and carry it with me.

And yet I am not speaking about DLLs.
Somthing like MyCoolButton.d which use some graphics
could be compiled *together* with such graphics avoiding of creation
of resx and folders - MyCoolButton package/module could be made
self sufficient.

I am not speaking of elimination of .res . They needed for e.g. defining application icon on Win32. My posts rather about component modularity than about anything else.

Self contained executables are lessly coupled with underlying OS and
particular
machine. Which is extremely good.

Andrew Fedoniouk.

On Sun, 6 Mar 2005 09:11:43 -0800, 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
> 
> 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.

Not so long ago, I wrote a simple GUI app for a client. Soon after receiving it, they asked for different images to be used. But by then, another client was also using the app. So, the best solution was for me to separate the icons, images, etc... (the UI skin) from the application.

-- 
Derek Parnell
Melbourne, Australia
7/03/2005 7:23:03 AM

Andrew Fedoniouk wrote:

>>Disk space is cheap, so Mac OS X just makes each application
>>have one copy of the (indentical) frameworks. Avoids DLL hell.
> 
> Probably yes, but for some aesthetical reasons I don't like to have
> something simple as Calculator.exe as a bunch of files instead of one.

Yes, that sounds great for a Windows application. And it would work
the same as "Calculator.app" would work on Mac OS X (shows as 1 icon)

> I would like to have it mono exectable just to be able to copy it on
> e.g. USB drive and carry it with me.

When you drag the application to the drive, it copies the entire dir.
When downloading the app from the net, it's a Zip or Disk image file.

> Self contained executables are lessly coupled with underlying OS and particular machine. Which is extremely good.

It was just a side note, really, that Mac OS X uses "bundles" instead
of files to package applications and frameworks. They're very similar.


For a cross-platform way of packaging several files into one archive,
I heartily recommend using .zip files. Compression and checksums, too.

I'm guessing you could pack such a zipfile into the EXE on Windows ?
(with Java, it's all in the same .jar and with Mac it goes in Resources)

--anders

I like the one-file thing. Maybe D apps on systems that require a bundle could auto-un-bundle on first run??

"Anders F Björklund" <afb@algonet.se> wrote in message news:d0fpuv$nhv$1@digitaldaemon.com...
> Andrew Fedoniouk wrote:
>
>>>Disk space is cheap, so Mac OS X just makes each application have one copy of the (indentical) frameworks. Avoids DLL hell.
>>
>> Probably yes, but for some aesthetical reasons I don't like to have something simple as Calculator.exe as a bunch of files instead of one.
>
> Yes, that sounds great for a Windows application. And it would work the same as "Calculator.app" would work on Mac OS X (shows as 1 icon)
>
>> I would like to have it mono exectable just to be able to copy it on e.g. USB drive and carry it with me.
>
> When you drag the application to the drive, it copies the entire dir. When downloading the app from the net, it's a Zip or Disk image file.
>
>> Self contained executables are lessly coupled with underlying OS and particular machine. Which is extremely good.
>
> It was just a side note, really, that Mac OS X uses "bundles" instead of files to package applications and frameworks. They're very similar.
>
>
> For a cross-platform way of packaging several files into one archive, I heartily recommend using .zip files. Compression and checksums, too.
>
> I'm guessing you could pack such a zipfile into the EXE on Windows ? (with Java, it's all in the same .jar and with Mac it goes in Resources)
>
> --anders

Matthew wrote:

>>When downloading the app from the net, it's a Zip or Disk image file.

> I like the one-file thing. Maybe D apps on systems that require a bundle could auto-un-bundle on first run??

That's what the system does, when you open a .ZIP or .DMG file...

--anders

> Not so long ago, I wrote a simple GUI app for a client. Soon after receiving it, they asked for different images to be used. But by then, another client was also using the app. So, the best solution was for me to separate the icons, images, etc... (the UI skin) from the application.
>

Hi, Derek,
This approach does not prevent you from using different skins as a system
of external files. It is up to you what to *choose*...

IMO, real skin engine demands not only static resources but also some code to be changed. So it is better to be able to pack themes into DLLs. And here comes import(...) again.

Huh?

Andrew Fedoniouk.

On Sun, 6 Mar 2005 13:48:32 -0800, Andrew Fedoniouk wrote:

>> Not so long ago, I wrote a simple GUI app for a client. Soon after receiving it, they asked for different images to be used. But by then, another client was also using the app. So, the best solution was for me to separate the icons, images, etc... (the UI skin) from the application.
>>
> 
> Hi, Derek,
> This approach does not prevent you from using different skins as a system
> of external files.

I know...that is what I did. The resources are now stored in files that are not the executable files. The resources are applied to the application at run time, and not at compile time.

> It is up to you what to *choose*...

Maybe I'm misunderstanding you, but actually it is up to the customer to choose the look and feel.

> IMO, real skin engine demands not only static resources but also some code to be changed.

That was not my experience. I documented the structure and nature of the skin files, and the client has created their own skins. The client was major US based hardware manufacturer and they are reselling the application under different 'brandings'.

> So it is better to be able to pack themes into DLLs.
> And here comes import(...) again.

But I suppose if they could have packed them into a DLL via compiling a specialized D program. That would have worked too.

-- 
Derek
Melbourne, Australia
7/03/2005 9:14:59 AM

>> It is up to you what to *choose*...
>
> Maybe I'm misunderstanding you, but actually it is up to the customer to choose the look and feel.
>

I mean developer can choose proper way of how to embed resources. Some components has to have fixed resourses other rely on skins. But again what will happen if someone will delete one piece of your system of resourses (skin/theme)?

Nothing new here but general principle is to wrap theme/skin into one
zip file or, which is better, in solid DLL. Just in case.
When you are getting 20000 customers then probability that someone
will remove .png or .bmp is high. Like in Windows
"Search all PNGs on C:\ -> Delete". Easy.

Yes there are use cases when customers need to modify their themes but this is a rare case. IMO of course.

Andrew.