OpenEuphoria

1. xpm resources

• Posted by irv Apr 29, 2015
• 2968 views

One of the things that has been a bother is how to handle images when creating Gtk programs. Normally, images are loaded from files (jpg, png, gif, xpm, etc...) at run-time. This isn't so good if you're going to distribute a program. You have to make sure the images are available regardless of where the program is installed/moved.

The solution seems to be to convert images (xpm, in this case) to Euphoria includes, and include them when binding, compiling, etc. They then become part of the executable, and can't get lost. Similar to the resouce complier on Windows, perhaps.

I've posted a zip file containing the necessary xpm_resources at:

https://sites.google.com/site/euphoriagtk/Home

This is a quick and dirty first effort. Comments and suggestions for improvement appreciated.

Edit: note - the executable tests in this zip are all 64-bit. You can re-compile re-bind, or whatever if you're using 32-bits.

3. Re: xpm resources

• Posted by irv May 04, 2015
• 2737 views

No doubt that would work, but it requires some extra steps each time the program is bound. It's easier just "include ..." the image(s) using Eu's normal include function. Also, it's unclear whether that will work with compiled-to-c programs. The docs only specify that you should bind your Eu program, then use bindres to append the 'resource'.

5. Re: xpm resources

• Posted by irv May 04, 2015
• 2728 views

Thanks, those appear to be beyond my skill level. I've updated the little (100 line) Eu program which works fine to convert .xpm's to euphoria includes. See link earlier. For other images, I can easily convert them to xpm.

Now I'm wondering what, if any, other types of things might need to be handled in this manner?

Anyone familiar with Windows resources have a suggestion?

7. Re: xpm resources

• Posted by irv May 04, 2015
• 2697 views

Care to share it?

9. Re: xpm resources

• Posted by Shian_Lee May 05, 2015
• 2679 views

I think that 2 kinds of mechanisms are enough:

1. For programs that need small amount of data (few icons, etc).
2. For programs that need lots of data (200 icons, other stuff).

1. Small data can be stored in a regular Euphoria sequence (of course):

sequence icons = repeat({}, 15) 
   icons[1] = {0,0,0,0,1,1,1,46,128,255,0,0,...} 
   icons[2] = {0,0,0,0,64,25,30,30,1,1,0,0,...} 
-- ... 

2. Lots of data should be appended to a single data file:

-- (not debugged) 
integer  fn_single, fn_source, byte, counter 
sequence files_list = {"icon1.gif", "icon2.xpm", "hello.txt", "logo.jpg",...} 
sequence files_start_end = repeat({0, -1}, length(files_list)) 
 
fn_single = open(program_name & "dat", "wb")  
counter = 0 
 
for i = 1 to length(files_list) do 
    fn_source = open(files_list[i], "rb") 
    files_start_end[i][1] = counter + 1  
 
    while 1 do 
        byte = getc(fn_source) 
        if byte = -1 then  
            exit  
        else     
            counter += 1 
            puts(fn_single, byte) 
        end if 
    end while 
 
    files_start_end[i][2] = counter  
    close(fn_source) 
end for 
 
close(fn_single) 

Now, I know it may look stupid... but this is straightforward, easy, simple and common.

11. Re: xpm resources

• Posted by petelomax May 05, 2015
• 2725 views

In case anyone wants to see it, I wrote a createDIBfromXPM function several years ago

axtra.ew

Pete

13. Re: xpm resources

• Posted by Shian_Lee May 06, 2015
• 2635 views

'include image' feature is useful and simple to use, as you said, but the last stable version 4.0.5 is from October 19th, 2012.

Currently the dev team should deal with the critical things: 64-bits support, try/catch/abort, optimizing makes magics, refactoring is a brilliant investment, and making Euphoria easy to install and use as a whole toolkit (+ IDE, GUI library, Setup program), and this is A LOT OR TOO MUCH WORK.

Binder for data is a simple, proven, easy to use, and a great solution when you have too many static data files. The Image2Include converter is simple to write and it works very well as expected. I've already wrote it many times in the past and deleted it when the work was done. Anyone with basic skills can bind data easily (or maybe I should write an easy to use one and add it to the archive).

As for Irv's subject - a binder for data is a solid solution for small amount of data as well as for huge amount of static data.

A small and powerful core + many well written Euphoria libraries, is more realistic, dynamic, and rapid way to improve Euphoria. If the core will get too big and complex - we might lose Euphoria for good.

15. Re: xpm resources

• Posted by irv May 06, 2015
• 2588 views

Erm.. point 1: I wrote the image to include converter already, less than 100 lines. Doesn't have to be attached to the compiler in any way. Nor does it affect compilation time. Eu already knows how to "include" a text file...

Point 2: XPM is the only graphics format I know of that is plain text. It's easy to convert to a Eu sequence using a plain text editor (WEE or Geany), and therefore easy to write a converter program. I will be happy to use jpg, gif or png images if you know a way to store binary data in a Eu include, and use it without having to write complex conversion functions.

17. Re: xpm resources

• Posted by irv May 06, 2015
• 2552 views

How do I display that jpg image?

19. Re: xpm resources

• Posted by andi49 May 06, 2015
• 2574 views

And? What do i find, some libs for using GDI on windows...

Oh, nice a GIF loader for MS-DOS...

---------------------- Information from the mail header ----------------------- 
--Sender:       Euphoria Programming for MS-DOS <EUPHORIA@MIAMIU.ACS.MUOHIO.EDU> 
--Poster:       Michael Bolin <michaeltom@GEOCITIES.COM> 
--Subject:      GIF loader bug fix 
--Sent:         Sunday, September 28, 1997 2:21 PM 
------------------------------------------------------------------------------- 
 

Oh, really great... Converts .jpg to .bmp and than you can load it on Windows (great idea...)

Could be done with Irfanview for nearly every Pictureformat.

 i_view32 c:\test.bmp /c=c:\giftest.gif 

Yes, The rest is very simple...

Have nice day.

Andreas

21. Re: xpm resources

• Posted by Spock May 06, 2015
• 2558 views

Irv, when you say that wrote an "image to include converter already" this is really an "XPM to include" converter. That's not quite the same thing. Years ago I wrote an image to include converter, ie, it takes native image formats (whatever GDI+ can load) and produces an efficient text format output (Eu sequence), albeit as if the image were a bitmap. To make it more efficient I had been toying with the idea of some form of compression, although, simply saving an already compressed image file (eg, jpg) in text format and decompressing it might be another option.

Perhaps an even easier solution is to simply save the (textified) image data to disk and then load it (with an image lib) as per normal. Come to think of it, this idea could be used for basically any type of data. A kind of install approach. To avoid redundant resaving each time program could check if file exists in folder and save if not there.

I think I would want to attach such functionality to the compiler. That way I can edit/change the data files with impunity and have them automatically converted at compilation time.

Of course, if the target system only allows one file to be installed, we might have a problem.. unless some complex conversion functions are written. Someone only needs to do this once..

Spock

23. Re: xpm resources

• Posted by Shian_Lee May 06, 2015
• 2533 views

Andreas, cheer up.

Irv knows GTK, and surely he can add 1 + 1, I'm not qualified to do it for him.

It's currently after midnight in Israel/Gaza. No artillery tonight and fresh air...

25. Re: xpm resources

• Posted by jimcbrown (admin) May 07, 2015
• 2530 views

But that's supported as well - https://developer.gnome.org/gdk-pixbuf/stable/gdk-pixbuf-Image-Data-in-Memory.html#gdk-pixbuf-new-from-inline

27. Re: xpm resources

• Posted by jimcbrown (admin) May 07, 2015
• 2523 views

D'oh. I thought it would be easier than this.

I think I was really thinking of gdk_pixbuf_loader_write() - see http://stackoverflow.com/questions/14121166/gdk-pixbuf-load-image-from-memory (the example loads it from a file first, but note that a memory buffer is passed into pdk_pixbuf_loader_write() - so if you have an Eu variable with the contents of the JPG, file I/O is unnecessary).

Of course, you can still make this work, if you really want to...

Yes.

You can do this too. One way is to add a simple C wrapper, and link it to a .so file. Basically, you add a function that returns a char* to my_pixbuf. Then you can pass that pointer to GDK.

Another way is to use a C program, that links to this C code, and then reads the contents of my_pixbuf (in memory), and writes it out to a file. Then you have a simple Euphoria app that reads that file back in, and does something like puts(1, "constant my_eu_pixbuf = " * sprint(contents_of_file)) - you'd then have to remember to use allocate_string() to allocate my_eu_pixbuf into memory and pass that pointer to GDK.

#ifdef __SUNPRO_C 
#pragma align 4 (my_pixbuf) 
#endif 
#ifdef __GNUC__ 
static const guint8 my_pixbuf[] __attribute__ ((__aligned__ (4))) =  
#else 
static const guint8 my_pixbuf[] =  
#endif 
{ "" 
  /* Pixbuf magic (0x47646b50) */ 
  "GdkP" 
  /* length: header (24) + pixel_data (20160) */ 
  "\0\0N\330" 
  /* pixdata_type (0x1010001) */ 
  "\1\1\0\1" 
  /* rowstride (240) */ 
  "\0\0\0\360" 
  /* width (80) */ 
  "\0\0\0P" 
  /* height (84) */ 
  "\0\0\0T" 
  /* pixel_data: */ 
  "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377" 
  "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377" 
  "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377" 
  "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377" 
  "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377" 
  "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377" 
  "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377" 
  "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377" 
  "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377" 
  "\314\223L\314\223L\314\223L\314\223L\314\223L\377\377\377\377\377\377" 
etc... 

It shouldn't be too hard to write an Eu app to convert this C source directly into Eu source. The resulting Eu source would look something like this:

constant my_eu_pixbuf[] =  
  /* Pixbuf magic (0x47646b50) */ 
  "GdkP" &  
  /* length: header (24) + pixel_data (20160) */ 
  {0,0} & "N" & {330} & 
  /* pixdata_type (0x1010001) */ 
  {1,1,0,1}& 
  /* rowstride (240) */ 
  {0,0,0,360}& 
  /* width (80) */ 
  {0,0,0}&"P"& 
  /* height (84) */ 
  {0,0,0}&"T"& 
  /* pixel_data: */ 
  {377,377,377,377,377,377,377,377,377,377,377,377,377,377,377,377,377}& 
  {377,377,377,377,377,377,377,377,377,377,377,377,377,377,377,377,377}& 
  {377,377,377,377,377,377,377,377,377,377,377,377,377,377,377,377,377}& 
  {377,377,377,377,377,377,377,377,377,377,377,377,377,377,377,377,377}& 
  {377,377,377,377,377,377,377,377,377,377,377,377,377,377,377,377,377}& 
  {377,377,377,377,377,377,377,377,377,377,377,377,377,377,377,377,377}& 
  {377,377,377,377,377,377,377,377,377,377,377,377,377,377,377,377,377}& 
  {377,377,377,377,377,377,377,377,377,377,377,377,377,377,377,377,377}& 
  {377,377,377,377,377,377,377,377,377,377,377,377,377,377,377,377,377}& 
  {314,223}&"L"&{314,223}&"L"&{314,223}&"L"&{314,223}&"L"&{314,233}"&"L"&{377,377,377,377,377,377}& 
etc...