[MiNT] SV: SV: form_button in XaAES

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

> From: Olivier Landemarre [olivier.landemarre@utbm.fr]
> Sent: 2007-09-21 09:21:24 CEST
>
> I don't know what is more logical for user (probably like for infoline), 
> but actually I know that for AES the most logical is like it is done in 
> all AES, because the toolbar is in the "working area" of the window, if 
> client wan't change height of toolbar, the AES have not this information 

I think you're right on this one, classic toolbars are drawn in the work area and must be considered by the application when/if using the rest of the work area. Thus the sliders must be implemented like they are today.

> (except perhaps to do a new wind_set(WM_TOOLBAR)), I think toolbar aes 
> extension is too poor to have slider under toolbar. Odd wan't to have 
> toolbar in diffrent positions, this is quite difficult to manage (where 
> should we put sliders if they are on left position for example) and 
> probably not very usefull. In my opinion, the only good way is a way to 

I strongly disagree. I don't know how Odd wants to implement these toolbars, but I would be surprised if they work like the current one. I would suspect a completely new implementation and interface. Imagine having flexible toolbars that the users can drag around in the window, rearranging at will and even dragging outside the window if they want :-) This would take a huge load off the application developer.

> create Frames in a window, like this we could add toolbars where we 
> need, we can have sliders in the good position draw by the AES with 
> uniform design, this is not too difficult to add in fact, each frame can 
> be a simple window in a mother window with some constraint, when the 
> mother window move for example all sub windows(frames) move 
> automatically by GEM, or close when mother window close etc. In fact I 
> have in MyAES  internally already a start of this approach.
... 
> I think a very simple way to do this could be:
> 
> win_handle_mother = wind_create()
> handle_frame1 = wind_create();
> handle_frame2 = wind_create();
> etc...
> 
> wind_attach_asframe(win_handle_mother, handle_frame1, some parameters to 
> define...)
> wind_attach_asframe(win_handle_mother, handle_frame2, some parameters to 
> define...)
> etc...

Or just another parameter to wind_create which tells which window to attach the new window to:

   win_handle = wind_create(.... attach_to_this_window);

> Application should manage messages, and receive for example all 
> classicals messages for click, redraw, sliders etc of the frame window, 
> moving or close mother window close or move all sub windows. Inside a 

I would suggest that sub-windows relates to the "mother window" like a real window relates to the desktop, i.e. that the sub-windows coordinates are relative to the "mother window". Then the application doesn't have to bother with moving/recalculating sub-windows whenever a window is moved.

> frame window we can put a toolbar classicaly.

Yes, but this would not be as flexible as it could be with multiple toolbars in one window. E.g. in Windows the user can very easily configure the toolbars by their needs, with your proposed solution this means dealing with lots of small windows. If you instead have one or more toolbar areas that each can display any number of toolbars, it's "just" a matter of attaching or removing a simple object tree. I believe this is easier for the developer, and also more flexible for the user.

Also, such "toolbar areas" would be outside the work area, so it would be very easy for the programmer to only relate to the actual work area and not having to consider the toolbar(s). If a toolbar/toolbar area is added/removed/resized/dragged outside/whatever a simple RESIZE-message is sent to the application to inform about the changed work area. And the sliders would only have to be drawn in relation to the actual work area.

Another thing that would be possible is that the user can drag toolbars between toolbar areas, and toolbar areas can be dragged around. The application doesn't have to care about this, just adapt to the new work area. A message should be sent to the application though, so it can save information about the toolbar layout for the next session.

There's also the possibility to let the user drag a toolbar outside the window, displaying it in a window using TOPMOST mode 2. The application wouldn't know the difference. Nothing of this would be possible with your proposed solution, atleast not without a lot of code on the application side.

I think we should differ between toolbars and dialogs - your proposed solution would work well where you need to display fixed dialogs in different areas of a window (like a mail client with a folder list to the left (dialog), folder contents list to the top right (dialog) and preview window to the bottom right (window with toolbar and text in the work area)). It would not work very well in a drawing tool where you have lots of tools and user might want to customize the toolbar to suit his/her needs. It could be done, but it would have to be done in application code.

Not that I have anything against sub windows though - I would like to have something like this as well!

Jo Even