And what is important to see is that when Pharo will use Athens fully, the system will manage the surface since it acts as the current display.
and AthensSceneView is a good to see a morph embedding its own surface and that should serve as a mini full world in which athens widgets can be drawn. Stef > So, in a meeting, Igor convinced me that surface cannot be handled at the > level of framework. The reason is that the surfaces in athens created by the > client applications have some application-level semantics such as extent, > that cannot be known by the framework. So, application has to integrate > session logic so that surface is initialized whenever image is restarted. > > Hence, checkSession default implementation in Athens throws an exception. > > For new comers like me, for creating surfaces and maintaining surfaces, this > is useful to understand the session checking code : > AthensFlakeDemo new openInWorld. > > I hope this helps others. > > Usman > > > > On Tue, Dec 3, 2013 at 11:21 PM, Igor Stasenko <[email protected]> wrote: > > > > On 3 December 2013 23:05, Usman Bhatti <[email protected]> wrote: > > > > On Tue, Dec 3, 2013 at 10:35 PM, Igor Stasenko <[email protected]> wrote: > > > > On 3 December 2013 15:21, Usman Bhatti <[email protected]> wrote: > > On Tue, Dec 3, 2013 at 2:29 PM, Igor Stasenko <[email protected]> wrote: > > > > On 3 December 2013 14:18, Usman Bhatti <[email protected]> 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. > > Usman, i have impression that you didn't looked at code at all. > > AthensSurface subclass: #AthensCairoSurface > uses: TCairoLibrary > instanceVariableNames: 'handle context builder id ftFontRenderer session' > classVariableNames: '' > poolDictionaries: 'AthensCairoDefs' > category: 'Athens-Cairo' > > > what you think 'session' ivar and checkSession method does there? > You can make subclass if you want and redefine default behavior. > > But my main problem that you still don't see that the code in example(s) is > NOT the lowest common denominator for all applications using Athens. > Lowest common denominator is Athens API. > Athens API defines and describes roles (surface, canvas, paints etc) and > their protocols, but NOT how to create/initialize and manage such objects. > > > > 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 <[email protected]> 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. > > > > > -- > Best regards, > Igor Stasenko. >
