Re: [MiNT] WCOWORK implementation : conclusions.

[Odd Skancke <ozk@atari.org>]

fre, 22,.07.2005 kl. 13.30 -0600, skrev evan@coolrunningconcepts.com:
> Quoting Odd Skancke <ozk@atari.org>:
> 
> >  What other ways would be better than WCOWORK, then? WCOWORK is a very
> > simple thing, it is about having the windowing work with WORK area of
> > windows instead of the FULL extent. That it. Apps can set the FULL area
> > of windows, and this is done like so; App knows the area onscreen it
> > wants to cover with a window - convert that to the corresponding WORK
> > area (wind_get(handle, WF_CALCF2w,...)) then wind_set(handle,
> > WF_CURRXYWH, ...). I've said this a million times now, what is the
> > problem?
> 
> I know how this works.  You don't have to repeat it.  But I still think this
> method is not as good.  Make a new more-powerful API with more features and
> better flexibility, and this API should be WORK area based instead of FULL.

 Ok, come up with a different sceme then. What goals do you have? What
goals to you want to see?

> 
> >  wind_calc() cannot be used here, because now you have two different
> > window types and wind_calc() is contextless. No way for the AES to know
> > which window type you mean. This is why I want wind_calc() depreciated.
> 
> Fine, my mistake.  wind_xget() then.
> 
> >  No. Either the application is a WCOWORK client or it is not. Lets keep
> > things simple and clean. I'm not even gonna open for possible havoc like
> > this by allowing the app to use one and the other. Only one or the other
> > is acceptible.
> 
> I don't believe that changing how API calls works is very clean at all!

 And why is this unclean? You think non-WCOWORK aware apps will see this
api change? This is why its ONE or THE OTHER.

> Nor do I think that making it impossible to link libs that know about the new
> mode is a good idea when another working alternative is available.   The real
> problem though is your absolute unwillingness to consider anything other than
> your own method.   Anytime someone has a problem with your ideas, you shoot it
> down without listening at all.  Unacceptable?   Please back that up with some
> logic as to why this is unacceptable.

 All I hear is complaints about what is not possible, this or that. I
have not been given other working alternatives. All I've been given is
"this may work without WCOWORK mode", "that could probably work too".
Single issues are looked at instead of the whole picture. Give me a
working alterative then, or shut the fuck up.

> 
> 
> >> I understand your concern.  But I think if you look into it, the problems of
> >> mixing the two can be solved easily, especially if you use the API I 
> >> outlined
> >> which completely seperates the two APIs.
> >
> >  This would completely work agains having WCOWORK in the first place.
> 
> Why and how?  Empty statement without reaseons to back it up!

 You just dont want to see, do you? I suggest you download the XaAES
sources and start pondering different issues that may arise from having
BOTH methods available simultaneously within the same application. Then
you implement your "working alternative". Let me promise you that you'll
find the complexity too great. And for what? What do you gain by
allowing both FULL and WORK area coordinates being used? Nothing but
trouble if you ask me.

> 
> > This adds complexity to both the AES and the application. So, no way I'm
> > gonna be talked into mixing ;-)
> 
> Actually, there isn't any real work involved when the application MAY use the
> "OLD WAY", as the AES already has to do this anyway to support old
> applications.  In fact, your way is more complex because the behavior of AES
> calls changed depending on some flag or mode.  This is where the complexity
> comes from.  In a clean design the behavior of these calls should not change.
> Then there is no extra work for the AES to do.

 Then I suggest you implement your working alternative, and let me know
how it works out.

 About the complexity, everything new, which application wants to
support IN ADDITION, adds complexity. This is unavailable. If, however,
the application wants to be an WCOWORK application, there is LESS
complexity involved. And many features will become available for the app
author at a much lower complexity-level than before. Some features even
BECAUSE of WCOWROK mode.

 For apps that dont know about WCOWORK mode, there is no changes.

 For apps that want to be both (that is, run on ALL AES's) there is
added complexity, but no more than a new API would create, actually
LESS.

 For apps that want to be WCOWORK only, less complexity is involved
compared to the FULL area scheme of today. I have to point out again now
that less complexity is not the goal. Its just a side-effect. A lot more
functionality is achieved combined with less complexity.

 So, reusing existing API because this is a 'mode' will generate less
complexity than implementing additional API's for WCOWORK mode.

 What problems do you have with this?

> 
> It doesn't encourage use of the old calls at all.  Thats what documentation is
> for, and providing an API that is WORTH people using it.   Don't force people
> to use some new flag that suddenly removes capabilities that you don't like -
> give them a replacement that is worth using!

 Ok, then I need you to teach me what to do. I dont know.

> 
> I don't see you removing gets() and strtok() and all the other really HORRIBLE
> calls from C libraries that lead to bad behavior, crashes, buffer 
> overflows and

 gets()? strtok()? Come again?

> security leaks.  Allowing a 3rd party library to open its own window without
> knowing if its WCOWORK work or not and having it actually work as expected,
> isn't as bad at all.  In fact, I don't see a reason not to.

 Hmm.. you mean the AES magically should know what the application
wants? A phsycic AES? A medium  AES that goes "hmm... hmmmmmm... I feel
this app wants FULL coordinates.. "

 Come on...

> 
> >  Again, this is not true. It would work as long as apps dont store
> > values. Problem is, they do store values. If keeping the FULL oriented
> > way of today and theme changes was the only goal, it would be enough for
> > clean apps (not storing values). But how does the AES know?
> 
> You see I can tell you aren't listening to me.  You didn't read what I 
> said.  I
> said to have a new call that tells the AES you can handle dynamic theme
> changes, and keep it seperate from WCOWORK.  Its already been shown 
> that Windom
> applications would not have this problem.   If you implemented this call, then
> I'm sure windom developers would add it to windom, and with just a quick
> recompile you'd have plenty of existing applications TODAY, that will 
> work just
> fine with dynamic theme changes, safely, without erwriting the application to
> use a new mode.

 Here it is again. One issue that may work with todays FULL window
coordinate orientation, depending on wether the app is correct or not.
You're right, I dont want to listen to this shit.

> 
> Tell me what is wrong with that other than you don't like Windom or 
> anyone elses
> way of doing things?

 No comments.

> 
> >  I do not agree. In a perfect world it would be possible, but as it is
> > now its not possible.
> 
> See above, and please read it.

 I have, and I fail to see any sense. Perhaps I'm stupid.

> 
> >  First of all, this "pointer to the data being held by Qed" philosophy
> > is what keep our system from being workable under MP and gonna make VM
> > hard to implement. By these words you just showed me that your ideas
> > need to be really examined before evaluated.
> 
> Stop - we are talking about completely different things.  In a regular 
> component
> system, the components are simple libraries, often dynamically loaded.  A
> pointer is fine.

 A pointer is fine? Even dynamically loaded libs have context they have
to consider. I always though these libs ran in the context of the user,
in user-space, of the lib, and if so, pointers are NOT fine. Have I
missed something here?

> 
> However, you can also get a pointer safely with your crazy method of gluing
> applications together using the /SHM.   Don't assume I don't know about 
> virtual
> memory and memory protection.   Methods that abuse the single address space of
> MiNT don't even come to mind for me since I've been on Linux for the past 12
> years.

 Well, with the idea I have, this added complexity is avoided. Now go
back and read your own comments about added complexity.

> 
> >  While you could do so, it would add alot more complexity to existing
> > applications than WCOWORK would. I'm also very instersted in knowing how
> > you want to share data? Please dont say 'pointers'!
> 
> See above.   Get data, not share data.  My way actually uses a simple message
> passing system internal to the application.  The data is simply shared.   Your
> way requires some IPC scheme of some sort, and since you are working with very
> large amounts of data that changes constantly, I would go for /SHM.

 Ok, here I really feel like I'm missing something. How do two processes
share data cleanly without using some form of IPC? Please I want to
know.

> 
> > exactly the reason the AES has to deal with it. And what does the menu-
> > bar have to do with this? You obviously dont know what you're talking
> > about here ;-)
> 
> You act like this is a very simple change.  As long as the applications 
> support
> your precious WCOWORK mode (by which you really mean to say that they use the
> working coordinates only and not the FULL, it is not dependant on your
> particular implementation that we don't like) then you can do these wonderful
> things that emulate a component system.  However, this is wrong.  QED and HW
> both have a menubar.   Which menubar is shown?

 This is a client/server'ish sceme. you do the rest of the math. And no,
this really isnt a very compilcated thing. Its just a new thing. And new
things like this needs new ways of thinking. See below for a fantastic
explanation about the menubar.

> 
> >  The idea is that a subwindow is, to the application bound to it, just
> > another window, and thats final.
> 
> And when the window is topped, that applications menubar is shown, but now you
> have 2 applications in this window.

 client/server scheme. Ofcourse the client's, the owner of the parent
window, menu-bar is ontop, since the app bound to a subwindow is
providing a service, i.e., it can be regarded as a server. I thought
this was obvious.

> 
> >  The owner of the window ontop's menu-bar is shown. The data edited by
> > qed is loaded by HW when told so by Qed using AES messages. Ofcourse, a
> > set of messages related to 'inplace windowing' would be necessary. This
> > way Qed can tell HW whenever it should rerender the data held in a file.
> 
> So these sub-windows can be TOPped seperately?  And then the menu bar flickers
> back and forth?  How does the user know which subwindow is the top one?  They
> are sharing the windframe, yes?  So the windframe wouldn't change.

 Se above.

> 
> And now you finally admit that WCOWORK isn't the only change required.  Now
> there is a set of new messages for inplace windowing. And you haven't said how
> the data is shared as it would be silly to push it all through AES events or
> save it to disk constantly.  You'd have a message that the data changed every
> keypress.  A real component system wouldn't need messages for this - 
> things are
> automatically updated on the fly.

 Are we confusing the idea I have that WCOWORK makes possible with
WCOWORK itself? Inplace Windowing IS NOT WCOWORK mode. It is a new thing
that WCOWORK makes possible.

 Would it be silly to use temp files for this, you think? Ok. You're
entitled to this opinion. When did I say that new messages was not
necessary for IPW (InPlace Windowing) to be usable? What I said is that
the windowing functions of a WCOWORK application needs next to no
changes when working with subwindows vs. its own windows. I also said
that perhaps it would be good to have subwindows complete slaves of the
parent windows, in which case a set of informative WM_messages is needed
to  tell the app about window geo-changes.

 You tell me I dont read what you said. Now I can tell you that you dont
read what I have said. WCOWORK is not IPW. IPW is possible because of
WCOWORK, if I decide to implement it.

> 
> >  If HW has a toolbar, that toolbar will show up in the subwindow,
> > because, once again, the subwindow is just another window to the
> > applications bound to it.
> 
> And if HW is getting the lower half of the window for its subwindow, then the
> toolbar goes in the middle of the window?

 Yes?

> 
> This sounds like a nightmare since the application has to be changed, and the
> user interface sounds like a horrible hack.  I don't like this idea at all.

 Thats because you dont understand the idea. This reveals that you have
been talking about a thing you just didnt get ;-)

> 
> >  Be very careful how you design the components system, and how they
> > share data. Lets try clean methods for once.
> 
> Trust me - everything I do is clean and cross-platform.   You are the 
> one trying
> to make a new class of applications using a very un-clean design.  The whole
> premise behind this subwindow idea is flawed - you've shown that existing
> applications cannot be used this way, and if you are going to change the code
> to make them work together, then you might as well change the program into a
> real component architecture that can deal with things cleanly.  Thats what you
> are trying to do, but they cannot run in seperate processes and be efficient,
> nor will the user interface be very consistent.

 Ohmygod. Cannot run in separate processes? What are you talking about?

> 
> I would much rather see a good multi-line text editor AES object, and a good
> auto-updating, printable, Canvas widget for holding VDI displays as I outlined
> before.  These are features real applications can use that will help
> programmers, and could be added to other systems.
> 
> Your premise that we must support your implementation of WCOWORK and throw out
> the ability to safely use older API calls with the new in the same 
> program (via
> linking of existing 3rd party libraries) is based on your desire to make this
> new subwindow thing work.   And  1 - you can do it with the mixed API, 2 - the
> subwindow idea is not good.  Lets allow the existing libs to work instead of
> forcing people to rewrite their apps for this crazy subwindow idea - few apps
> will ever take advantage of it.

 Ok, you obviously do not know what you talk about, and I'm really
looking forward to your "working alternative" solution.


 Odd Skancke