Re: [MiNT] WCOWORK implementation : conclusions.

[Odd Skancke <ozk@atari.org>]

fre, 22,.07.2005 kl. 20.23 -0600, skrev evan@coolrunningconcepts.com:
> Ozk,
> 
> I'll respond in private - only because my brain hurts too much to 
> figure out how
> to continue on my own stuff right now - and the whole world doesn't need to
> continue to read this.

 I'll put it out on the list, since thats where this belongs.

> 
> Quoting Odd Skancke <ozk@atari.org>:
> >  Ah, what have you done so far, then? Any links I can find info about
> > your work at?
> 
> Is this a contest or a discussion?  You see .. when you start things off this
> way, it is not productive.   Lets stick to the topic at hand.

 Not sure what you mean here. I'm still interested in information about
things you've done, tho.

> 
> >  A lot of the other things that WCOWORK would open for could not be used
> > if there are chances the application mix the two orientations. This is
> 
> OK .. I almost see what you are saying, but please enlighten me on what other
> features WCOWORK will do for us.  Lets keep the subwindow thing out of it for
> now since thats a much larger set of disagreements, and I'll use the

 Well, I'll keep that in as a brick in the big picture.

>  
> example of
> wind_create() since your subwindow idea specifically says that the application
> within the subwindow won't be opening a window, but it still must be WCOWORK
> compatible.

 Yes, correct.

> 
> Opening a new window by the FULL area instead of the WORK area shouldn't cause
> problems, after all, there will surely be times when this is desired, and we
> can do it in WCOWORK mode as well as compatibility mode.
> 
> Normally you pass the rectangle returned from wind_get(0,WF_WORKXYWH,...) to
> wind_create() if you want the window to be full-screen.  Correct?

 Yes.

> 
> Using WCOWORK mode you'd translate this rectangle from the FULL to the WORK
> coordinates using wind_xget() and then pass these coordinates to 
> wind_create().
>   End result is the same!  Correct?

 Yes. Or you could just do exactly the same as for normal mode, and have
the resulting WCOWORK coordinates returned by wind_xcreate().

> 
> Now I know you hate this argument, but, if you have a WCOWORK 
> application, but a
> library doesn't know about WCOWORK and needs to open a window, you have a

 You're right, I hate this argument. WCOWORK was a new thing, and
nothing supports it yet. I wont create hacks now just to support old
libs.

> conflict.   You'll pass it events and redraws as normal.  Why not allow
> wind_create() to work as that old library expects and give a new call for the
> WCOWORK code to use?   The only difference is that wind_create() takes 
> the FULL
> area without WCOWORK and it takes the WORK area with WCOWORK.  Since you can
> achieve the same effect by translating between rectangles, then how is this so
> different from just leaving wind_create() alone and making a new
> wind_create_by_work() or something?

 This would be possible, yes. However, you would have to have
corresponding functionality for wind_open(), all wind_set() mode working
with coordinates too. wind_create() also sets the MAX window
coordinates, which the AES uses as a limit when user resizes the window.

> 
> My feeling is that as long as people feel the only way to maintain compatibily
> is by not using WCOWORK, then the benefits may never be realized.  If we can

 And this is the feeling I wanted. It is better to remain all 'old'
style than to break something 'new' even while its being developed.

> ease peoples fears with a compromise, then adaptation and acceptance can be
> accelerated.  And as long as wind_xget() can calculate between WORK and FULL
> rectangles, then someone can and will use them to treat the modified API the
> same as the old API.  In my opinion, if we can ease some peoples fears by
> making the new features their own API calls, then this works in our favor for
> quicker acceptance.

 If that was possible, I would have suggested that route. But to me this
looks like a half-hearted solution.

> 
> Pretend I'm really stupid and explain to me the specific cases where 
> this logic
> is incorrect?

 First, the idea of WCOWORK was to completely remove FULL extent control
out of application and give it to the AES. For this to work, I think
that you cannot even leave the possibility for application to set window
coordinates by FULL area.

 One of the key points when applications want to, for example, keep the
same WORK area after changing the window-layout (widgets) is to use
wind_get(handle, WF_CALCx2x) to get the corresponding WORK area, and
never store this for itself. This was going to be new programming
guidelines for WCOWORK. I know that WinDom linked apps is clean in this
respect, and allowing some things intended for WCOWORK only would break
loads of apps that is NOT WCOWORK aware and not linked against WinDom. I
wanted to keep 100% compatible here. Thats why I wanted a new 'mode' in
which the API have different programming documentation. And this also
makes sure the already documented API's dont change.

 I know you dont like the idea of IPW, but that is an idea I liked. And
therefore it stays as an argument. 

> 
> > why. Lets take the simple example of themes. How do you make immediate
> > theme changes work reliably if the application can use the FULl extent
> > of windows in parallel to the WORK area? And how can you say that this
> > generates less complexity? I dont get that.
> 
> The only thing an application needs to be able to understand theme 
> changes is to
> not save any information about the sizes returned by the AES.  Do we agree on
> that, or can you think of a case where this would not be true?  I'd like to
> know since the Windom folks make this claim, and after careful 
> consideration, I
> agree.

 I agree on that. However, very few applications are clean in this
respect. So instead of breaking existing behavour, introducing a new
'mode' was the solution for me.

> 
> >  Besides, linking agains code that is outdated in a new application is
> > not good programming practice. I would not even use this as an argument.
> 
> Most people here are using OSs machines and applications that are 
> ancient.  Most
> of the things on my Linux box are less than a month old.   I can't say if its
> bad programming practice.  In theory, and well written library can be used for
> quite some time without problems.

 This is probably because they were nicely designed from the get go.

> 
> Now, bringing us back on topic, I'm talking about libraries that don't
> understand WCOWORK, and you are calling these "outdated" and not "good
> programming practice" and not allowing me to use this as an argument.

 You do understand that? WCOWORK is a 'new' feature. And therefore it
must have support throught the entire application to work correct. So,
yes, I still think this is not a valid argument.

> Considering that NO library uses WCOWORK right now, then by your 
> definition all
> libraries are outdated, and its bad programming practice to use them.

 Yes, correct. Either WCOWORK mode is supported or it is not.

>   
> That sort
> of logic isn't going to get WCOWORK accepted any faster.  Its just 
> going to piss
> off people making libraries.

 I didnt see this as a reason not to implement WCOWORK. Either the
application authors want to be WCOWORK clean or they stay with the old
way. Either way is a lot better than a sweet mix of the two orientation
systems. Btw, this problem will be encountered for every new thing
introduced, not just WCOWORK. And if library/application authors dont
want to update their libs when new stuff becomes available, I dont see
the reason to work on new features anymore. XaAES is now quite up to
other AES's.

> 
> > Besides, only one of the libs which application is linked agains should
> > be the GUI frontent, like windom. If other libs also uses  the AES, or
> 
> Only 1 library should be the event loop, that is true, but it is perfectly
> acceptable to separate the event loop from the rest of the application.  There
> are more than 1 valid abstraction, and I think its a bit egotistical to call
> all other approaches wrong.   Are you positive you aren't dismissing this
> argument simply because it doesn't fit well with your own plans?

 I also think that only one lib should control the windowing in the
application. This lib should be like WinDom does it. But you are right
in that this usage of different libs all doing their own little AES
windowing will break WCOWORK because of the danger of one not being
aware of it. Btw, if you think only one lib should have the event loop,
then the API's these libs work with must be standarized in someway,
because events happening on a window created by, lets say wout, will be
sent to the application. I wonder how this is handled under this kind of
design.

> 
> The main loop of an application can very well be totally separate from the
> library that opens the windows - in fact this is pretty much common as many
> systems have an event loop library with callbacks for you to insert.  
> The event
> loop library doesn't open the windows.

> 
> > if windom dont know WCOWORK, the application simply cannot use WCOWORK
> > mode. Or, like someone said before, two libs, one knowing about WCOWORK
> > while the other dont .. I think this sounds so messy it isnt an argument
> > at all.
> 
> Again, I think its improper to simply dismiss an argument without reason based
> on your personal biases.  The only argument that isn't valid is the one were
> you make no points at all except to call the other person names or call them
> stupid or tell them they don't understand or flat out tell them its an invalid
> argument.  The only bad point is the one you fail to make, and if its 
> so messy,
> it should be really easy to show me why without name calling or blatant
> dismissal.

 Well, sorry about that. I'm not able to give you any more examples. But
this is not my problem anymore.

> 
> >  Because there are functions/features the AES cannot make available if
> > the application can use both orientations. You do understand that if you
> 
> You keep saying there are all these features that simply can't work if address
> the window by its FULL size instead of the WORK size, and yet I can call
> wind_xget() and convert the FULL size I would normally give to the API into a
> WORK size for the new API, and achieve exactly the same thing.  So what 
> are the
> new features that this change makes possible?

 The thing here is that when FULL area of a window is needed, the
programming guidelines was to clearly state how to deal with that. Since
this is more of a special case, perhaps it could be a good thing to put
a 'lock' upon the applications windows incase theme changes happens
between a wind_get(handle, WF_CALCx2x) and wind_set().

> 
> > allow for both orientations, different api's, one window can be
> > controlled by both api's? This takes away the AES's control of the
> > window's exterior. This will create confusion for application authors
> > wishing to support functionality unlocked by WCOWORK.
> 
> Again, how is the AES more in control of the exterior?  And what is the new
> functionality?

 Because the application does not control the FULL area. That is, there
are no 'offsets' from FULl to WORK. The biggest problem today is that
many apps store this offset. And because of this, a window's deltas
cannot change. One of the foundations of WCOWORK was to remove such
considerations completely, allowing the AES to do whatever it wanted to
areas around the WORK area without the application needing to know. This
fact alone opens up for a lot of possibilities. If there was even the
slightest possibility that the application _could_ use the old api in a
mixed api solution, the AES needs to consider this, and either disable
functions/features depending on this, or send messages to the
application when FULL/WORK relations change.

> 
> >> not at all saying that a programmer should toss both APIs together like
> >> a mixed
> >> salad.  They can and should use the WORK mode exclusively, but I 
> >> don't see why
> >
> >  Well this is exactly what you are saying.
> 
> No, I'm saying the new mode should be used, but that the old methods shouldn't
> fail to work just because the rest of the program uses WCOWORK.  Isn't this
> part of what modularity and encapsulation are about?   One part of a program
> shouldn't be able to cause problems for another part of the program, and this
> is exactly what this global mode does.  Its counter-productive to the goals of
> encapsulation and modular programming.

 I dont agree.

> 
> >  If you are writing a WCOWORK oriented applications, you would have to
> > update the lib your using too. Otherwise, as I've said before, WCOWORK
> > looses its purpose. New application using old libs .. man, is this even
> > a valid argument? Does this mean XaAES and MyAES should work with libs
> > created in 1989?
> 
> UHmm .. you have a habit of going off to these extremes to try and make your
> point, but it doesn't work.  We aren't talking about 1989.  No current library
> uses WCOWORK in 2005.   Should XaAES and MyAES work with libs written in 2005?
> YES!

 And they do, dont they?

> 
> I'd ask how WCOWORK loses its purpose, but I've already pretty much asked that
> twice above.
> 
> >  I've not said something bad happens, I've said that WCOWORK is rendered
> > useless. By that I mean the AES cannot trust the application to work
> 
> Again, you restate that it will be useless and lose its purpose, but 
> not how or
> why this is the case.

 I gave you the reason for this.

> 
> > exclusively with WORK coordinates, and thus cannot do all the fancy
> > stuff discussed. Or do you want the old api to return error under these
> 
> Again, more "fancy stuff", or "features" and all this.  Please interate what
> this features are and why they won't work.  You've mentioned theme 
> changes, but
> I think enough people have mentioned that there is no reason why they 
> can't work
> without WCOWORK as long as no AES data is saved between calls.

 Easier implementation of future features like the ones I mentioned in
another post. And again the assumption no data is saved between calls.
The real situation isnt that simple. The AES needs to know that the
application dont use the FULL extent for anything.

> 
> > conditions? What a mess. About complexity, allowing both orientations
> > would double the amount of api calls, double the amount of aes message
> > types, and for what? Nothing! Since there's a chance the application
> 
> UHmm .. it wouldn't double the amount of calls.  There would only be a short
> few.  In fact, the number of API calls that WCOWORK changes is the number of
> new calls that would be needed.

 That was what I meant. Doubling the amount of calls that deals with
window coordinates.

> 
> I am not talking about adding ANY new AES Message types, and if you 
> think I did,
> then perhaps this is where our misunderstanding is.  I never suggested 
> that the
> message types be any different.  I saw to use the original messages and 
> message
> types, but translate the coordinates when the application reads the event.
> 
> This is possible by replacing evnt_multi() with a new, more flexible API
> allowing event_multi() to continue to work as before.  This would be of great
> benefit for a number of applications outside the scope and purpose of WCOWORK,
> such as the ability to add new message types like the KEY_UP and KEY_DOWN that
> was discussed before, and possibly IO events when we get that afar.

 You now have two event points. And this is not adding complexity?

 Regarding key make/break messages; this is very easy to implement in
the kernel/XaAES. What isnt as easy is that for this to be possible we
need a low-level keyboard driver for all known hardware. ACIA driver is
already implemented, and this could be working there. Milan hardware is
what is stopping this right now.


> 
> Making this new call would translate the FULL coordinates to the WORK
> coordinates when the event was returned to the application.  This could
> actually be another winning situation since if a theme changes while an event
> is waiting in queue, the coordinates aren't changed from the FULL area to the
> WORK area until the application actually reads them, which could help prevent
> possible race conditions.

 This is a good point. Should be easy to do this in the current
implementation.

> 
> >  Your ideas are too heavy for me to ponder. I dont understand how you
> > can have such ideas and not see the havoc allowing for two different
> > orientations will create.
> 
> Is it more havoc than what wind_xget (WF_CALCF2W) is already doing?  
> That alone
> lets you combine any WCOWORK mode call with a quick wind_xget conversion to
> essentially revert to the old API.

 CALCx2x does not do anything but convert an arbitrary rectangle from
one coordinate orientation to the other. While the thing you say above
is quite true, it is the fact that the AES looses control of the FULL
extent that was the consern of mine. By that I mean the AES cannot do
anything to the window's exterior without notifying the application (add
compleixty) or not at all, like today.

> 
> >  How about ideas that is a bit more down to earth? lets go small steps,
> > my limited capacity needs that.
> 
> If you mean the component system vs subwindow thing, well .. I've put quite a
> deal of thought into how to get all the best features of COM/DCOM and CORBA
> without nearly the amount of code complexity and bloat.  I've spent years
> looking looking into solutions before finalizing the details of my plans.  I

 Do you have any documents describing your plans? I would be interested,
honestly.

> don't expect anyone to actually use what I'm creating, especially not until
> I've completed something working and sizeable to judge from.  I will say that
> the subwindow idea looks okay on the surface, but I think there are some
> limitations that are best solved by using a user-space component system 
> instead
> of trying to link multiple applications together.

 The subwindow idea only works if the AES can trust apps to not consider
the FULL area like today. If you look away from the implementation
suggestions I had regarding the subwindow idea and only keep the fact
that 'this kind' of windowing (that is, the AES can place one
applications window whereever needed) is made possible by WCOWORK mode
because it doesnt matter to the application what is around the window.
Therefore there can be only one or the other, and not both coordinate
orientation at once.

> 
> And before any of this, I think there are more immediate needs that 
> more people
> might want to make use of.   These are:
> 
> 1 - A way for MiNT to load plugins, even if they are just LDG plugins, 
> having a
> real API for this instead of a cookie would quite helpful.
> 
> If you missed it before, having a file-system driver that exports a hierarchal
> (tree-based) namespace would be ideal, even if it just exported the directory
> tree from somewhere else but allowed for loading and sharing of the plugins in
> that space transparently to the application that opened this virtual
> filesystem.  You could very well modify the /SHM filesystem to do this as a
> plugin is basically a shared memory area that is dynamically loaded 
> from a real
> file.  I don't think modifying /SHM in this way would hurt ... you'd 
> simply have
> a subdirectories available such a /SHM/PLUGINS, and /SHM/PLUGINS/CODECS,
> /SHM/PLUGINS/CODECS/IMAGE, /SHM/PLUGINS/CODECS/AUDIO, or something like that.

 This is out of scope from the work I was doing. WCOWORK would have
helped here, I'm sure, but the above are things not really concerning
the AES kernel.

> 
> 2 - A multi-line editor buffer GEM object just like the single line one 
> but with
> some extra editing capability.  I know you'd rather embed a full application
> like QED for this, but you could also simply make it a plugin that 
> XaAES itself
> uses, which would allow the user to change the behavior of the object and what
> editing keys are used by changing the plugin.  This would also allow bug fixes
> in such an object to be done independantly of XaAES.   I believe the author of
> MyAES is doing a similar approach, and I'm really interested in what he does.

 Yes, agreed here. I dont think my IPW should be used by the AES kernel.
The reason for this I think that would create security holes big enough.
A plugin or something trusted by the OS (loaded at boottime) is the best
solution here.

> 
> 3 - A "canvas" widget.  Basically a GEM object like any other, except that you
> can give it VDI calls which should be relative to the object itself and not
> based on screen coordinates.  There should be an explicit "clear" to empty the
> canvas which would revert to whatever the default window backing for the
> current theme was, and possibly some other calls to manipulate this object,
> such as "Print" to dump the contents to a printer!   The redraw is done by
> simply using objc_draw() since the coordinates of every VDI call on the 
> list is
> relative to the object, so the AES should be able to get the required 
> state from
> the object and walking down its list of VDI calls.  This may not be the 
> fastest
> way to do things, but I'm sure various optimizations can be done later and it
> would certainly make application programs easier!  And as an object, you could
> have various canvas objects that are repositionable within a document.

 I'm not sure I understood this.

> 
> >  I have no problems making compromises, as long as the things we're
> > talking about is possible.
> 
> Don't dismiss things as impossible without first hearing every side.  If
> something won't work - explain it to me so that I will understand.   If
> something is a better solution, I am definately going to be the primary
> supported.   I have no problem throwing out the old for something better!

 I have tried repeatedly.

> 
> 
> << lots of repetitive stuff deleted >>
> 
> >  I have read your point of view, and I have argued against it. Then I
> 
> No - you just said I don't understand and that it would destroy all the 
> features
> of WCOWORK.  You said it over and over, but did not qualify this 
> statement with
> specific features nor why my alternative would be so much worse than what you
> have already suggested, with the exception that my way might be more 
> acceptable
> for the few people against WCOWORK.

 Yes, I have said that it destroys the very idea of WCOWORK. If the AES
cannot trust the application to never set window coordinates using FULl
area, the point of WCOWORK vanishes.

> 
> > view. Well .. what am I supposed to do when these views are downright
> > wrong? I'm not gonna agree just to keep the peace. All I have done is
> 
> Is it wrong because you dont agree with it?   If not, then show me why.  Teach
> me!

 I have tried. Unfortunately I have failed. If you dont see what I mean,
I just cannot make more arguments because I'm empty. Doesnt matter
anyore anyway, tho.

> 
> > same set of API. I would have hoped that ppl do more research before
> > they argue. I have nothing against healthy discussion, but when it come
> > down me forcing things on other, I loose interest.
> 
> Hey man, I'm dead serious.  You show me your way works better and really does
> solve more problems than mine, and I'll be your biggest supporter!  Call me
> names, belittle me, act childish, and tell me to shut the fuck up, 
> without ever
> telling me the reasoning and details behind what you believe, and I can only
> assume that you resort to the name-calling because you don't have the 
> technical
> reasoning to back up what you say intelligently.  How can I support what you
> believe when you do that?

 I dont think I can. I have told you what the definitions of WCOWORK is
and why. I coldnt do more than that. I dont understand the purpose of
WCOWORK if the points of implementing it is killed by keeping the FULL
oriented coordinates too. The AES cannot benefit from WCOWORK in  this
case. And with WF_WORKXYWH working, there is no need for WCOWORK in your
mixed api (new api/old api) sceme.

> 
> >  Hmm.. you're not gonna take over XaAES?
> 
> No - like I said - I'm working on other things.  They will be easier to 
> move to
> XaAES with a real plugin system and with WCOWORK mode.  Yes, I still want WORK
> coordinates for my project - actually I want all drawing to have the origin

 You dont need WCOWORK at all if you want to keep the FULL oriented
windowing too.

> based on the work area, but that requires VDI support - and I think Klockars
> may actually add that in a such a way that you simply take the X + Y from the
> WORK area when the window is moved or changed coordinates and set the 
> origin in
> the VDI, then you only need to worry about the w + h of your work area.  The
> area of user drawing would be from (0,0) to (w,h).   SWEET!

 Yes. I thought WCOWORK would be very nice related to such things.

> 
> I know it doesn't make sense for you to agree with the idea behind 
> WCOWORK, and
> then want a different implementation, but .. I think there are more benefits
> another way, and no more bad points than yours.

 You're right, I dont. WCOWORK is not needed in your sceme. The ONLY
benefit WCOWORK has in a mixed API is less complexity for application
authors. It cannot be used for features I thought it would unlock then.

> 
> >  Good work.
> 
> GEM, GTK2, or WXWindows.   Haven't decided yet.   But if I'm not getting
> anywhere here - its time to move on.

 You have XaAES sources at hand. Start working.




 Odd Skancke