emacs-devel
[Top][All Lists]
Advanced

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

Re: Gtk tabs in emacs, new branch.


From: Stefan Monnier
Subject: Re: Gtk tabs in emacs, new branch.
Date: Sat, 10 Apr 2010 15:00:05 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

>>> Are there any concrete examples of other uses?
>> I can imagine switching the buffer of one of the windows (in an ECB-style
>> frame, for example).
> Isn't that a window configuration?  I don't get it.

Not quite: e,g. you can create a new tab for "toto.c", switch to toto.h,
then resize some windows, then select the "toto.c" tab and it will
switch the buffer to toto.c without reverting the window sizes.

>> In mpc.el I could imagine using it to switch
>> between various selections.
> I don't know what mpc.el is, so the statements has no meaning.

It's emacs/lisp/mpc.el (new in Emacs-23.2), a front end (client) for the
Music Player Daemon.  So think of it as switch between different
selections in Rhythmbox's browser.

>>> But implementation for the primary use case (window configurations)
>>> should not have to suffer because of other uses.
>> I still don't understand what kind of suffering you're referring to.
>> If you could describe more concretely (e.g. what kind of undesirable
>> user-behavior could happen in which case and why).

> The most obvious thing is flickering.  When the user clicks on the tab Gtk+
> switches tab, there is nothing you can do about that.

I think we need to define "tab" here.  For me a "tab" is a little
rectangle on the screen with a label.  The actions on this tab are
usually linked to switching the content of an X window that's
drawn underneath.
>From what you write I get the impression that your notion of a "tab"
includes not just the tab itself but also the window underneath.

> Depending on what was drawn in that widget previously, something else
> is shown than what was shown in the old wiindows before.

If I understand correctly, that means that Gtk tabs have a built-in
semantics of "switch the window underneath the tabbar".
That's obviously too restrictive for the kinds of use cases I suggest,
so we'd have to hack around it, e.g. by creating a dummy 0-pixel high
X-window where Gtk can "switch tabs" at its heart content without
bothering us.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]