Re: Infrastructural complexity.

[Lennart Borgman <lennart.borgman@gmail.com>]

On Sat, Jul 18, 2009 at 2:05 AM, <joakim@verona.se> wrote:
> Thomas Lord <lord@emf.net> writes:
>
>> On Fri, 2009-07-17 at 14:46 -0400, Chong Yidong wrote:
>>
>>> I recall that we had an inconclusive discussion over the relative merits
>>> of two proposals, one by Joakim that (IIRC) relied on window parameters,
>>> and another by Martin that uses more built-in code.  Does anyone have
>>> any new thoughts about this?
>>
>> Yes.
>>
>> One observation is that RMS posted some pretty
>> challenging questions about whether or not
>> window groups are a good design, and these have
>> gone unanswered:
>>
>> http://lists.gnu.org/archive/html/emacs-devel/2008-05/msg01769.html
>>
>> I think window groups are clearly not a good
>> design, essentially because the questions he raises
>> don't have good answers that I can see.  But,
>> there's no need to dwell on the negative.
>>
>> I've been looking at Eclipse screenshots and I
>> regularly use programs like the OpenOffice suite
>> and Gimp and so forth.  I think I have some "feel"
>> for what the goals are here.

One thing many GIMP users have complained about is the lack of a
docking ability for the tool windows. (Ie keeping everything in one OS
window which simplifies switching between different applications and
make things looks nicer and less cluttered).

A small note on this: In my opinion the "docking ability" does not
necessarily have to be within one OS window. It could instead be on
the display level. By this I mean that switching to for example GIMP
could show just GIMP and hide/minimize all other application windows.




>> The "GUIs" you are going up against here tend
>> to have window system windows with a main edit
>> area.

Or several.


>> In addition there are floating
>> dialog boxes

Which I think should be implemented in Emacs. (On w32 the needed OS
level feature is "always on top" + tinier header/border parts.)

>>  and "tear offs".

What is that?



>> There are other GUI details in the IDEs and other programs.
>> Tab bars, and toolbars and such.   I can imagine clean
>> ways to add those to the extent they aren't already there
>> but nothing even remotely close to "window groups" seems
>> a reasonable abstraction -- at least unless it can be explained
>> much better than it already has been.
>>
>> Something like "framelettes" seems a much better design
>> to me.
>>
>> FWIW, of course.
>> -t
>
> When I did my "windowgroups" patch, I wanted to find a simple
> abstraction on which you could build other things. The ECB already does
> all the Eclips:ish things you describe above, and I just wanted to find
> the smalles set of primitives suitable to get rid of the advice ECB
> uses. In my mind most of the issues in RMS observations are answered in
> some way by ECB, and "windowgroups" lets ECB be included in Emacs, since
> advice is no longer needed.
>
> A "windowgroup" is similar to an Emacs frame, inside another emacs
> frame. I like this better than using several Emacs frames.


Windowgroups is a nice thing. Framelettes is also a nice thing.

I think windowgroups might be the basis for framelettes. One thing
that windowgroups does not take care of is the visual feedback to the
user which tells which windows that belongs to the group. The concept
of framelettes might help with this, but is not the only possible
solution.

However some kind of solution for the visual feedback is necessary.
Using a visual extra "frame" is one solution. Background coloring
another. Please make room for those in windowgroups.