Re: [MiNT] [Mint-cvs] [FreeMiNT CVS] lib/gemlib

[Odd Skancke <ozk@atari.org>]

tor, 14,.07.2005 kl. 02.18 +0200, skrev Arnaud BERCEGEAY:
> Hello,
> 
> >  WCOWORK is a new operation mode, and it is not mixable with the
> > existing FULL-area orientation.
> 
> so why new functions to convert FULL/WORK area ?

 In TosWin2 one can add/remove widgets in the 'config window..' dialog.
What happens in that code is as follows;

/* *************** */
 wind_xget_grect(w->handle, WF_CALCW2F, &v->work, &full);
 wind_close(w->handle);
 wind_delete(w->handle);
 w->kind = new_kind;
/*  Here is usage of xcreate, it gets you the maximum coordinate
 *  the window can have at create-time
 */
 w->handle = wind_xcreate(w->kind, &gl_desk, &v->full);
 /* If you want to snap the full coordinates, you can have this.. */
 if (snap)
 {
   snap(&w->full, char_w, char_h);
   wind_set_grect(w->handle, WF_FULLXYWH, &w->full);
 }

 wind_xget_grect(w->handle, WF_CALCF2W, &full, &w->work);
 wind_open_grect(w->handle, &w->work);            
/* ****************************** */

 Remember that such things as the above is more a special case, very
rare in applications. Even in this example (not really an example, as
this is acutally how TosWin2 does it), WCOWORK makes this a lot easier
and readable by the author. Therefore the wind_get(WF_CALCx2x) modes.

 Let me know how you would do the above..

> 
> >  Agreed on wind_calc() should return error. I dont agree wind_set
> > (WF_CURRXYWH) should return error. Its in the name CURR as in current.
> > Do not confuse CURRENT with FULL.
> 
> I don't confuse.
> 
> WF_CURRXYWH is for current size of the window
> WF_FULLXYWH is for the size of the window when at it is at full size.
> 
> ATM, both of them use FULL area of the window in paramters.
> 
> In WCOWORK only mode, both of them shall set/get the WORK area of the  
> window if your implementation is consistent.
> 
> FULL is not for FULL area of the window. FULL is for "when at full size  
> after clicking on the fuller widget".

 See above in the example.

 when you create a window, you can get the true full coordinates of the
window you created by either using wind_xcreate() (difference between it
and normal wind_create() is that xcreate returns 4 more values, the max
coordinates), or by using wind_get(w->handle, WF_FULLXYWH).

 In the case of a theme-change where a fulled window's borders are
getting smaller/larger, and no longer covers the true full area, the
application is notified of this (not discussed yet). For Applications
that are totally WCOWORK aware, a normal WM_MOVED message is enough to
adjust this. The next wind_get(w->handle, WF_FULLXYWH) will give it
correct FULL coordinates. Per definition, using WCOWORK mode means the
app must use the AES to get such info whenever needed (WF_FULLXYWH, for
example), and not 'collect' such info for itself. In this case there is
no specal handling needed by the application.

> 
> So what's the way to set window at FULL size ? I mean set the FULL area of  
> the window on the whole desk area ?

 wind_get(w->handle, WF_FULLXYWH, &w->full);
 wind_xset_grect(w->handle, WF_CURRXYWH, &w->full, &w->work);

> 
> > If anyhting WF_WORKXWWH should
> > return error, as this mode looses its meaning.
> 
> looses its meaning, maybe, but i don't see why it should return an error.

  But you saw that WF_CURRXYWH should return error ;-))

> 
> >> why a library specialised to print strings in a window must not exist ?
> >> Because it uses AES functions ?
> >
> >  I'm no lib expert, but I think Evan had a point saying that if such a
> > lib actually uses the AES by itself, it is not nicely designed.
> 
> I want to listen more. Why a library should not use AES function please ?

 I dont know if its me not explaining correctly or if I'm being a total
idiot, not being able to describe what I mean more clear. Help anyone!

> 
> >> So cflib must be trashed because that "library" do some AES call ! same
> >> for windom ! my GEMSCRIPT library should be trashed because it manage  
> >> AES
> >> message and send AES messages to other application by calling AES
> >> functions ?
> >
> >  cflib is an AES library.
> 
> What's an AES library ? A library that use AES functions ? So if i call my  
> previous library an "AES library", it well designed ?

 Would you use both cflib and windom?

> 
> > Having two libs using the AES in this scenario is just plain bad
> > design.
> 
> I still don't understand.

 I'm out of breath, I dont know how to explain what I mean.

> 
> typical AES application is
> - an event_multi() loop catcher
> - a dispatcher of all MU_xxx events to other function.
> 
> one "AES library" do the event_multi() loop and dispatch events to others.

 The 'others', which is receiving the, lets use windom as base, windom
events are not libs, but the user (.app)'s, 'glue' if you will,
functions. If not, this design is not very clear.

> another "AES library" (woutlib) gets the events received by the 1st "AES  
> lib" and perform what's needed to handle the wout window.

 If this is so, the design is just broken.

> 
> Where's the hack ? It's just the way most AES applications works.

 woutlib should just create the output. The user (.app) should be able
to use windom to display woutlib's output in a window. If woutlib
creates/opens/administers windows on its own, alongside windom, those
are two libs one cannot use together. Kills consistency.

> 
> > Doesnt matter if the libs output is a form or a text or image or
> > mplayer. Neither should NEVER go to the GUI by themselves.
> 
> So a lib shall not get informations from the AES... and shall not get  
> events from the AES, and shall not write using VDI functions ? seems  
> stupid to me. To sum up, a well design library shall only compute numbers ?

 You choose to not understand, dont you?

> 
> 
> >  Again, only one lib should deal with the GUI. In your case this would
> > be WinDom.
> 
> And if i put all the code of windom in the application, i can use another  
> library that call AES functions ? Again, the rule "at most one library  
> shall call AES functions" is non-sense rule.

 Did I explain things this badly? WinDom and gemlib are two different
libs. Two different goals. WinDom never calls the AES, it uses bindings
provided by gemlib, right? So, per definition, WinDom can work on any
GUI, as long as gemlib emulates AES. This is good design. Why? Because
only ONE lib does the management (window, events, etc.) and only ONE lib
has actual AES function binding (the gemlib). how do you think this
works if any other lib also calls the AES, perhaps even using its own
bindings?

> 
> I agree that the application have often just one main evnt_multi() loop,  
> and of course this piece of code is localised at only one place (the  
> application or a library), but i still can understand why other libraries  
> are not allowed to call AES functions.

 Ok, I have tried to explain.

> 
> If i split windom in several libraries (ApplXxx library, EvntXxx library,  
> ShellXxxx library, WindXxxx library, etc...), then it's become a bad  
> design ???? really amasing :/

 yes, it would be bad design, because those libs would depend on
eachother anyway.

> 
> >  Well, if, for example, libeditbox or libplaympeg or whatever goes to
> > the GUI for itself, those libs are just plain useless, and not portable
> > and not usable at all in apps.
> 
> I'm lost. I don't see the link with the subject.
> 
> I've never said that libraries SHALL use AES functions and SHALL manage a  
> window ! it's a so stupid statement !
> I only said that libraries MAY use AES functions and MAY manage a window.

 and you even said that one lib may do things the other lib dont know
about. Talk about stupid statements.

> 
> With the new COMPONENT feature, most libraries may only contain the  
> feature of the COMPONENT (management of received messages and events), but  
> some libraries may still exist to handle a complete window (such lib will  
> internally use various COMPONENTs and some extra stuff like the management  
> of a menubar and a toolbar for this window).

 I hope for Gods sake that the components are AES (or GUI) unaware, and
that the API of those are such that they can output without the presence
of an AES (or GUI). WinDom should provide means for the user (.app) to
'bind' the output of one lib to whatever the user wants. If the
goddamned lib does AES tricks on its own, this will be impossible. Only
WinDom should manage the GUI side of things.

> 
> >  Variable definition? There are two different, non-mixable operating
> > modes. What is so hard to understand here?
> 
> Nothing hard to understand.
> 
> I've perfectly understood that this may easily lead to incompatibility for  
> modular applications, but you state that you don't want XaAES to support  
> application currently developped with windom because using AES functions  
> in a lib is a bad design (i love your justification).

 I dont want to support?! Yeah, you're a nice one :) You are the one
telling me that you would discurage ppl from using WCOWORK and XaAES,
and not put this support into your libs. And we havent even started
constructive discussions yet. Your panic is created by the design of
your new developments, I'm sure.

> 
> > because of idiotic library design, WCOWORK mode cannot be used.
> 
> Once again, please argument why using AES functions in a lib is "idiotic"  
> ? I'm sure it is not.

 Once again, please reread what I have said. AES functions in A lib is
fine. AES functions in MORE than A lib is not fine.

> 
> >  Killing your work? I'm not interested in killing your work. Ok, listen
> > closely now, ok? You can use either WCOWORK mode, or standard mode, but
> > NOT both at the same time. ok? See?
> 
> I've perfectly understood that since you introduce WCOWORK feature. On the  
> other side, i think you haven't read carefully my posts because your only  
> answer was "AES lib is bad design".

 yeah right.



 Odd Skancke