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

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

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 ?


 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".
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 ? 


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.


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 ?


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 ? 


Having two libs using the AES in this scenario is just plain bad
design.


I still don't understand.

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.
another "AES library" (woutlib) gets the events received by the 1st "AES lib" and perform what's needed to handle the wout window. 

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


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 ? 



 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.
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.
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 :/ 


 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.
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). 


 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). 


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. 


 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". 

best regards,
Arnaud.