[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

 Hello!

Jo Even Skarstein skrev:

-----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?
I think that sending any event to a specific window will make it easier for us to implement things later on, not just toolbar handling. So, yes I mean sending any event through wind_event(), like you do with keyboard events and form_keybd(). 




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.
I think a click sets focus. If user clicks on the 'app area' of a window, the app still passes the event to wind_even(). wind_event() will then return all keyboard events to the app until focus changes to a place where AES is supposed to handle it, like in toolbars. This will even make it possible for, for example, alt+TAB (or some keycombo we decide on) to move focus out of the 'app area' into toolbars, so keyboard navigation becomes very smooth. So, if the application always pass events through wind_event(), it can be sure the event belongs to one of the window areas it controls, like the text in a texteditor window. If not, wind_evennt() consumes the event, and app reenters evnt_multi(). 




  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.


 Yes :)




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.
The current implementation does not move the object data out of application's address-space, no. I dont know how clever this would be, tho. One process's resources should not be in any other context than the owners, and I dont know how I like this sharing of resources via OS context. Altho it seems likea good idea, I have to think about this for a while :) 




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.
Sounds like a good idea, but I need to grasp the idea of having the AES own a client's resources like that. 




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.
Yes, this is the plan :) Actually, the code for this is already in place; you can place toolbars and arrange the window's widgets in anyway you want. I just need to write a good GUI config app so that themes can be created easily. 


 Best Regards,
Odd Skancke