[MiNT] SV: SV: SV: form_button in XaAES

["Jo Even Skarstein" <joska@online.no>]

> -----Opprinnelig melding-----
> Fra: mint-bounce@lists.fishpool.fi
> [mailto:mint-bounce@lists.fishpool.fi]På; vegne av Odd Skancke
> Sendt: 7. september 2007 20:05
>
> > 	form_toolbar_keybd(window, toolbar, event);
>
>   Hmm.. if we first make new things like this, lets try to make it as
> simple as possible. The app should not need to keep track of focus,
> except from cases where it places the cursor upon opening a window, or
> such. So;
>
>   wind_evnt(handle, event); would suffice. And then this function

Isn't this the same thing with a different name? And without the toolbar
handle? Or do you mean to pass ALL events this way, not just keyboard
events?

> send the event to. If it needs to place an event at a specific edit
> field, it can use the normal form_keybd() function.

That's true. But in the case where you have a window with both toolbar(s)
and a work area, someone must decide where the focus is - toolbar(s) or work
area. Who should be responsible for this, the app or the AES? I would
suggest the AES, a click on a toolbar gives it focus, a click on the work
area give focus to the work area. Also, keyboard navigation must consider
the work area as an object to pass focus to somehow.

>   Yes. And while we're on the subject. I think that we need to change
> things so that you get a toolbar handle when you attach one to a window.

If you want to attach several toolbars to a window you obviously need
handles.

> This handle is not necesssarily the tree address, I want to hide the AES
> object trees from the app via objc_data() function call. This is under
> development.

I like this idea! Do you move the object tree from the application to the
AES as well? That would be great for sharing objects/resources between
applications. E.g. if you make a component based desktop with many small
application each doing their tasks, they might want to share their icons
instead of loading them once for each application.

> I want to hide this from the app. objc_data() is a function call that
> apps should use to get/set data in object trees. This frees the AES to
> organize things without having to consider compatibility :)

I once experimented with a slightly modified way of placing objects relative
to each other. Instead of using characters as coordinate units, I attached
"rulers" (used INDIRECT on each object, pointing to two linked list) to each
object, where I used tabulators to position child objects. Then I made a
simple recursive function that traversed the tree, calculated the absolute
positions and let objc_draw handle everything from there. The advantage of
this was that I could use proportional fonts and still be able to align
objects properly independent of font and fontsize. It looked great :-) XaAES
could do something similar if you load the RSC into AES space and hides the
data from the application.

> To attach a toolbar to a window;
>    long tbhandle = wind_set(handle, tbtree, orient);
>   where handle is window handle
>         tbtree is object tree (or handle)
>         orient is how to place it within window

Looks fine to me :-) With "orient" I assume you want to make it possible to
place toolbars vertically, to the right, bottom etc? And perhaps stack them?
If you do, you should let the AES move these around in the window as the
user requests (like toolbars in Windows), and send the application a message
whenever the work area geometry changes. You could even drag a toolbar
outside a window, opening a new window (perhaps using TOPMOST mode 2) for
it.

Jo Even