[Pharo-dev] Roassal Bug related to Athens?

Usman Bhatti usman.bhatti at gmail.com
Thu Dec 5 14:47:53 EST 2013


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 <siguctua at gmail.com> wrote:

>
>
>
> On 3 December 2013 23:05, Usman Bhatti <usman.bhatti at gmail.com> wrote:
>
>>
>>
>>
>> On Tue, Dec 3, 2013 at 10:35 PM, Igor Stasenko <siguctua at gmail.com>wrote:
>>
>>>
>>>
>>>
>>> On 3 December 2013 15:21, Usman Bhatti <usman.bhatti at gmail.com> wrote:
>>>
>>>>
>>>> On Tue, Dec 3, 2013 at 2:29 PM, Igor Stasenko <siguctua at gmail.com>wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 3 December 2013 14:18, Usman Bhatti <usman.bhatti at 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.
>>
>> 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 <usman.bhatti at 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.
>>>
>>
>>
>
>
> --
> Best regards,
> Igor Stasenko.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131205/1463c330/attachment-0002.html>


More information about the Pharo-dev mailing list