I'm using the latest Pharo beta image (1.1) from http://gforge.inria.fr/frs/download.php/27025/Pharo-1.1-11367-Betadev10.05.1.zip
Now, core images have an update button that updates things to the state of the art. What do you do on non-core images?
Simply wait that somebody release a new one. The situation is like that since extra packages could break when core is updated and we could not control it. This is not optimal but for now we cannot do better.
Related
I am working on the development of a software artifact that uses fabric.js-1.6.6. The code will be used by other programmers who might be adding/removing objects to/from the canvas and interacting with them.
In order to avoid delays caused by other programmers' refreshing routines, I decided to implement a global refreshing function that is transparent to users of my code. The refreshing routine looks like this:
(function render() {
fabric.util.requestAnimFrame(render);
canvas.renderAll();
})();
I know it might be not super efficient (as the canvas gets refreshed all the time), but I am preventing other programmers from having to deal with rendering the canvas on their own when implementing specialized objects whose appearance changes permanently and, thus, require the canvas to update.
Recently, I tried to migrate my code to fabric 2.0.0 beta 4 but the canvas is not updated anymore. Any ideas on how to fix this?
Also, is there any better, more efficient way to have a permanent canvas refreshing routine? What I decided to do was inspired on the Animating polygon points official fabric demo, but my canvas requires a significantly higher number of objects that are changing all the time, so this might not be the best strategy.
My personal suggestion is to start watching at 2.0.0
The new version implement a new method called requestRenderAll that will make use of requestAnimationFrame properly.
Consider that having the canvas autorefreshing every 16ms may be an overkill.
To me the most elegant solution is to ask other developers to use requestRenderAll and not renderAll.
chained calling of requestRenderAll will have no effect, since till the animation is still in request stage, other do not get requested.
I've seen that some Google's or other open source projects have resource directories like /drawable-v14 or /drawable-hdpi-v11.
Now, I understand what this means: all devices with SDK larger or equal than v11/v14 should use these images.
But what is the purpose of this? Why and when should I use them? Why devices of HDPI resolution and SDK v11 should ever use images different than HDPI devices and SDK 10?
I just cannot see when I will ever use one image for SDK 10 and another for SDK 17, for example. Makes no sense to me.
As a side note, the usage of resources /values-v{11/14/17} is logical and has the practical benefit.
This can be use in order to style your icons to the current UI guidelines on the given Android version.
Android has had a lot of evolution on its GUI style from its beginning. In Cupcake, icons had to show a 3D effect with a shadow. With ICS, there is more flat icons. And it will keep on changing with android 5 and more... (Let's watch the Google i/o 2014 to know more about it! ... by the way: its today!)
So basically you can stick to the GUI guidelines even from different Android versions. It's probably not the only use case but it is one of them.
I'm running in a bit of OC situation here. I'm developing an application using LWUIT 1.5. So I'm almost done with the application, I've already added transitions in fact. But I noticed that the application is lagging on the phone(My current test phone is a Nokia C3-00). The transitions are starting halfway.
Do you guys have any advise on how do i optimize my application? I know I could use the Next Form properties of the Form, but I wouldn't want to always show a "splash screen" every time the user will go to another screen.
Nokia's are often very slow with translucent images, any image that contains a translucent image would be pretty slow which includes image borders. Another culprit is overly narrowly cut image borders, there is a workaround for this in Codename One though.
Remove the theme and create a blank or theme that only uses colors. See if speed improves.
Assuming it does then slowly remove suspect elements from your theme. If it doesn't then see if you load large images etc.
Can someone explain in simple terms what an egl image is, and an example of when I would want to use one? I know it can significantly increase performance, but I'm having trouble finding documentation. Before I try and really figure it out, I want to make sure its even worth learning.
Thanks.
So a year later, I have become more of an expert in Android graphics and actually wrote a white paper about EGL Images. If my company lets me publish the paper externally, I'll post it here. For the time being, here is a short answer.
An EGL Image is simply a texture whose content can be updated without having to re-upload to VRAM (meaning no call to glTexImage2D). One of the only drawbacks, besides increased code complexity, is that the application developer has to handle synchronization themselves. In apps that I've written, I had to implement my own "internal" swapchain of EGL Images and manage all the locking primitives myself. Thus, a call to eglSwapBuffers swaps front and back framebuffers as usual, but in a seperate thread there are 2 EGL Images swapping front-to-back as new content becomes available.
The Khronos documentation is at:
http://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_image.txt
http://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_image_base.txt
On the other hand, given how opaque most Khronos documentation is, this may not help much. I haven't been able to figure them out myself.
I have an OLD server running DG/UX that will in the near future be unsupported. I have some character based oracle forms that need to be migrated off of this machine. Does anyone know what sort of migration strategy Oralce has for upgrading these Character Based reports. It doesnt have to be the newest version, it doesnt even have to be to a GUI version, but I do need to migrate to a supported OS such as linux.
The easy answer is to tell you to check out Migration from 6i to 10g.
Having done it before, what I think the much more useful answer is to tell you to rewrite those forms and reports from scratch. Probably in another tool - especially if you want to have a web interface, etc. rather than being hobbled by an ancient Java runtime.
There are products out there that will let you translate the old forms code into PL/SQL. Kumaran is an example of one, but I found it buggy and had to do a lot of hand editing of the code to get it work the same as the original.
As far as I'm concerned, the CUI is dead so you might as well go all the way to a GUI. The last time I was looking at it, there was almost no documentation for CUI forms and frequently things that worked in the GUI wouldn't work in the CUI at all.
There are some problems you may run into in converting CUI based forms applications to GUI.
Sometimes there is validation and special processing done when the user moves to the next or previous field/block/etc. When you switch over to a proper GUI, your user can skip those events by just clicking on another field. So you are left with two choices - #1 audit all of the forms or #2 disable navigation in the form with the mouse
Option #1 is less work than redeveloping but look at how much work we've already put into it.
Option #2 your users will HATE you and come after you with pitch forks and torches. They will perceive that they've got nothing of value for all the work you put into it. Then you will end up doing Option #1 anyway.
Sometimes a UI that works fine in (or is required by the limitations of) a CUI is just plain wrong and breaks the UI metaphor that users are used to working with in the rest of the GUI (e.g., a pop-up window with list that you have to select an entry in rather than pull down where you can just pick the right value directly)
When converted to a GUI the CUI may end up with different fonts, text sizes and other formatting defaults than a freshly written form (it did for me). So now either the whole set of forms has to be updated to follow Oracle's new default theme for forms/reports or every new form/report has to reverted back to the old clunky style you had before - or it will stick out like a sore thumb (and your users will want them all to be like the pretty one now).
Not the answer you wanted; huh. But you can use this as an excuse to get out of the Forms/Reports upgrade tread mill and maybe even clean up some of the hacks that have had to happen over the years.