FWD » Core Development » User Interface

For details see #2480 notes 84 and 85. This task is to implement support for those images.

The base for embedded images is ready but the investigation shows we do not have the functionality to load them from jar file. It sounds strange but if the approach I offer for these images is:
- store the arrow images on the client side p2j.jar file.
- use the current tools to load button images. The schema we now use is: load image from application jar file, if not found - use client side file system.
- if we do not find the image on local client side file system - try to load from p2j.jar on the client side.
- I suggest to store the images as 32bpp icons at place where we have "gclogo.ico" file.
- use ImageHelper to add missing functionality.

That's the plan.

In the 4GL, does one specify the special image name as a quoted string ("btn-up-arrow") or as unquoted text btn-up-arrow?

In the 4GL, is it possible to load your own file btn-up-arrow in preference to the prepackaged one? For example, if you place a file of that same name in the propath, does it load?

In the 4GL, does one specify the special image name as a quoted string ("btn-up-arrow") or as unquoted text btn-up-arrow?

Only quoted string("btn-up-arrow") is possible, otherwise even 4GL check syntax does not pass.

In the 4GL, is it possible to load your own file btn-up-arrow in preference to the prepackaged one? For example, if you place a file of that same name in the propath, does it load?

It is not possible to replace image btn-*-arrow with another image with same name. 4GL always load prepackaged images if the file name is specified as "btn-*-arrow".

- store the arrow images on the client side p2j.jar file.

Yes.

- use the current tools to load button images. The schema we now use is: load image from application jar file, if not found - use client side file system.
- if we do not find the image on local client side file system - try to load from p2j.jar on the client side.

This approach would fail to match the described behavior. Instead, when on GUI only, why not match the special image names and when matched, bypass the app jar load and the local client side file system search?

- I suggest to store the images as 32bpp icons at place where we have "gclogo.ico" file.

Yes.

- use ImageHelper to add missing functionality.

What is missing?

What is missing?

Loading an image(not default icon for main window) from p2j.jar file.

OK, then the only thing I want you to change in the plan is to bypass app jar and local client filesystem searches with the special image names.

All my button tests work fine with this update. So waiting for Hynek to checking in. Or may be there are the notes from review.

Code Review evl_upd20150417a.zip

1. In ButtonWidget change the import com.goldencode.p2j.ui.client.*; into import com.goldencode.p2j.ui.client.ImageHelper;. This is an exception to our normal rule of using wildcards. Normally, we would not want code in the parent package to be importing code from a child package. In this case, the reuse is useful but we don't want it to lead to more usage of that child package.

2. About this:

The button picture is the handcrafted copy of the same button from Windows 4GL. Hope it is not copyrighted.

The pixels of the Windows images are copyrighted. We CANNOT use the clipboard to copy/paste the pixels into our own file. We CANNOT take a screen shot of the images and then save the pixels off into a file. But we CAN duplicate the exact result of the images by hand-editing the pixels in an image editor (e.g. GIMP). In other words, Microsoft and/or Progress cannot stop us from making something ourselves that looks exactly the same. You cannot protect the look of the result, only the actual file/pixels that they have in their implementation are protected by copyright. We don't infringe on their copyright as long as we are by-hand creating images that look the same.

Did you copy/paste the image pixels/files or did you manually draw the pixels using an image editor?

Code Review evl_upd20150420a.zip

It is good.

The only I can say was "stolen" is the size of the images (16x16) and how it looks.

This isn't stealing. Such things are unprotectable elements of the images. In other words, copyright law does not extend to these things.

Just copy/paste does not work because the quality of this operation is not good enough.

Good, because copy/paste would have been illegal.

So I had to manually create image in GIMP and edit every pixel to have exactly the same result. Then export to 32bpp icon image from GIMP. Is it acceptable approach?

Yes, this is exactly what was needed. There is nothing wrong with this.

Code Review evl_upd20150422a.zip

Please move the public static final members above the private members. And the private static final members should be moved below the public static final and above the private members.

Otherwise I'm fine with the changes.

Code Review evl_upd20150422c.zip

It looks good.

Now I can merge evl_upd20150422c.zip with 10841 and start testing, OK?

Code Review evl_upd20150429a.zip

The merge looks good.

Constantin has an update that will be checked in before yours. He should be done on Friday. After that, you can merge once more (it should be easier) and then go ahead and test.

Code Review evl_upd20150501a.zip

It's good.

Now the conversion testing is not required because is was already done(as part of the previous update to 10845) for the changes I've made.

Agreed.

Please merge to bzr 10846 and get this tested.

Code Review evl_upd20150503a.zip

It looks good. Check it in when it passes testing.

Greg Shah wrote:

Code Review evl_upd20150503a.zip

It looks good. Check it in when it passes testing.

The testing completed, no regressions found. The resuls: 10846_eff7cc1_20150504_evl.zip. The test TC-MISC-REPORTS-015 had to be run in standalone mode to get passed. Will be committed and distributed shortly.

evl_upd20150503a.zip has been committed as 10847.