On Tue, Dec 3, 2013 at 10:35 PM, Igor Stasenko <siguc...@gmail.com> wrote:
> > > > On 3 December 2013 15:21, Usman Bhatti <usman.bha...@gmail.com> wrote: > >> >> On Tue, Dec 3, 2013 at 2:29 PM, Igor Stasenko <siguc...@gmail.com> wrote: >> >>> >>> >>> >>> On 3 December 2013 14:18, Usman Bhatti <usman.bha...@gmail.com> wrote: >>> >>>> Igor, >>>> >>>> I had a look at Athens demo to understand how to manage sessions and >>>> surfaces because Roassal uses AthensSurface and there is a defensive >>>> mechanism in place in Roassal to initialize the surface in case it is not >>>> done. In the meantime, I have discovered that the red rectangle bug is >>>> present in Athens demos as well. >>>> >>>> So, to reproduce. >>>> AthensFlakeDemo new openInWorld >>>> save image >>>> open image >>>> >>> >>>> I tested in Moose 5.0. >>>> >>>> 1. Should I open a bug entry in Pharo? >>>> >>>> only if you intend to fix it. because this demo was not intended to be >>> 'fully featured, end-user compatible >>> and fool-proof demo'. it just a demo to show animation and discard it, >>> but if you insist this is a bug, >>> feel free to fix it. >>> >> >> Unfortunately, I wont have time for this. For me it would have been good, >> had Athens provided an example of session management as a good client so >> that example-oriented people like me could understand easily. Because, >> otherwise, I'll have to look at the code of NativeBoost and that adds to >> the level of complexity because I would do things with trial and error. >> >> > No need. There is one example: look at AthensSceneView > > >> >>> >>>> 2. With my superficial knowledge of Athens, my guess is that the >>>> session management can be done in Athens so that Roassal (and other tools >>>> built on top of Athens) do not need to do it. May be it is the case already >>>> but the demos are not using it then. >>>> >>>> I disagree. >>> >> Because then, files can also open/close and delete themselves >>> automatically, so you will be left only to do reading and writing... >>> Resource management is an application-level responsibility, not >>> framework level. >>> I cannot predict in Athens, how often one wants to create/destroy or >>> (re)use surfaces, and therefore i cannot >>> create and dispose them when i see fit within framework. >>> Correct me if i wrong. >>> >> >> I think this doesn't compare to file handling because there are many >> types of operations possible on files and that are application-specific. >> Here resource management is actually exception-handling: I should not give >> to my client a surface that does not exist any more. Now, of course, if >> there is some application-level intelligence is involved, we cannot put >> that in the framework. >> >> Surface is like file, you create it, delete it.. write to it.. > the management of surfaces is absolutely out of scope of framework. > More than that, surfaces is not something which you operate with usually. > Because usually its just a canvas. > Still, I will maintain that a minimalistic session logic should be built by default in Athens. Because otherwise each application has to maintain a session instance variable and a logic to test that session hasn't changed in between to keep a surface alive, which is lowest common denominator for all the applications using Athens. regards, Usman > > But I would understand the absence of such a mechanism in the framework >> but then a tutorial should explain to novices/first-timers how to do it. >> >> > this sort of things is tiniest (but of course necessary) parts of whole > application, and usually will belong to some service layers built around/on > top of athens. > in future, sure thing you won't need to care about it. > > >> Usman >> >> >> >> >>> >>> >>>> Usman >>>> >>>> >>>> >>>> On Mon, Dec 2, 2013 at 5:14 PM, Usman Bhatti <usman.bha...@gmail.com>wrote: >>>> >>>>> Hello Igor, >>>>> >>>>> Moose 5.0 is using Athens as default canvas for Roassal and we have >>>>> bug with Roassal that seems to be related to Athens. >>>>> http://code.google.com/p/moose-technology/issues/detail?id=1019 >>>>> >>>>> I think it is related to the fact that we create a surface in the OS >>>>> with Athens and once we quit the image, the surface is destroyed as well. >>>>> So, when image is restarted with the visualization trying to use the >>>>> surface, we get the error. >>>>> >>>>> Could you point to what possibly can be done to avoid this error? >>>>> Merely checking the existence of an appropriate drawing surface in Athens >>>>> every time visualization is drawn, would it suffice? >>>>> >>>>> regards, >>>>> >>>>> Usman >>>>> >>>> >>>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > > -- > Best regards, > Igor Stasenko. >
