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

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

Hello


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);
Oh yes good idea to create and attach in same time, this is quite more easy to do.
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.
In fact it is more simple than this in my idea, application manage nothing of frame windows with coordinate, it have only to know where it is(if needed) on where redraw, to know where it is a wind_get(WORKXYWH) is enough and to redraw the classical wind_get(FIRST and NEXTXYWH) are enough. There is nothing to do for application, because with the specific wind_create (or a function like this) constraints should be put and with this AES choose to manage the frame if need. 


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.
Really I think developpers prefer have a toolbar with more than one object and manage as they wan't. Frame are not dedicated to toolbar, it's only a way to cut a window in part, to have diffrent regions. 


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.
Actually Toolbar are not redraw by application but by AES, and dragging outside or do something like this is an other story! Change position of toolbar is the same changing a frame, but this is quite more easy to do inside aes kernel, because all is based on windows. 


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.

Yes quite simple.


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 you not understand what I perhaps do a day, and probably you not know me, I dislike add complicated things, and all I do is to have more and more simple. All you wan't is possible and even more simple with a frame because this is windows and all is based on it, not passing by windows concept, is rewriten a parallele system to window, this huge and difficult. 


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.
Really we not speek same thing, I speek cut window and you discribe in fact the DFRM api of Windom look at: 
http://windom.free.fr/dfrm/

This what you need I think.



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

Jo Even

Regards

Olivier