RE: Gtk tabs in emacs, new branch.

RE: Gtk tabs in emacs, new branch.

[grischka]

 > It's not clear to me, for example, what you mean by tabs (necessarily)
 > doing the same thing to different objects.

See, tabs are defined by their shape, more by their placement and
mostly by their action.  Which is to "switch content in the associated
window".  If it does not perform this action then it is not a tabs
control but just a row of buttons.

To give another example:  A scrollbar is defined mostly by its action
to "scroll content in the associated window".  Of course you could use
the scrollbar widget just as well to adjust your speaker volume, but
then it wouldn't be a scrollbar, even if it looked like one.

Aside from that it is completely unnecessary and boring to overload
widgets with alien functionality.  If for example you like to have
a row of buttons to switch color themes in the buffer, then well,
just use a row of (possibly colored) buttons.

--- grischka

Side windows (was: Gtk tabs in emacs, new branch.)

[Juri Linkov]

> To give another example:  A scrollbar is defined mostly by its action
> to "scroll content in the associated window".  Of course you could use
> the scrollbar widget just as well to adjust your speaker volume, but
> then it wouldn't be a scrollbar, even if it looked like one.

There is a task in etc/TODO:

  ** Compilation error navigation bar, parallel to the scroll bar,
  indicating where in the buffer there are compilation errors.
  Perhaps we could arrange to display these error indications on top
  of the scroll bar itself.  That depends on to what extent toolkit
  scroll bars are extensible.

If it's possible to display such tab-like indications
on the scroll bar, is it still called a scroll bar?

If it's not possible, then what is an alternative?
Maybe, 1-column side bar windows?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Side windows (was: Gtk tabs in emacs, new branch.)

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Wed, 14 Apr 2010 02:31:30 +0300
> Cc: drew.adams@oracle.com, emacs-devel@gnu.org
> 
> There is a task in etc/TODO:
> 
>   ** Compilation error navigation bar, parallel to the scroll bar,
>   indicating where in the buffer there are compilation errors.
>   Perhaps we could arrange to display these error indications on top
>   of the scroll bar itself.  That depends on to what extent toolkit
>   scroll bars are extensible.
> 
> If it's possible to display such tab-like indications
> on the scroll bar, is it still called a scroll bar?
> 
> If it's not possible, then what is an alternative?
> Maybe, 1-column side bar windows?

The fringe, I think.

Re: Side windows

[Jason Rumney]

Eli Zaretskii <eliz@gnu.org> writes:

>>   ** Compilation error navigation bar, parallel to the scroll bar,
>>   indicating where in the buffer there are compilation errors.
>>   Perhaps we could arrange to display these error indications on top
>>   of the scroll bar itself.  That depends on to what extent toolkit
>>   scroll bars are extensible.
>> 
>> If it's possible to display such tab-like indications
>> on the scroll bar, is it still called a scroll bar?
>> 
>> If it's not possible, then what is an alternative?
>> Maybe, 1-column side bar windows?
>
> The fringe, I think.

The fringe nearest the scroll-bar is the right place to display the
indicators I think, but we need a new mechanism to display them, as they
should not scroll with the buffer text.

Re: Side windows

[Juri Linkov]

>>>   ** Compilation error navigation bar, parallel to the scroll bar,
>>>   indicating where in the buffer there are compilation errors.
>>>   Perhaps we could arrange to display these error indications on top
>>>   of the scroll bar itself.  That depends on to what extent toolkit
>>>   scroll bars are extensible.
>>>
>>> If it's possible to display such tab-like indications
>>> on the scroll bar, is it still called a scroll bar?
>>>
>>> If it's not possible, then what is an alternative?
>>> Maybe, 1-column side bar windows?
>>
>> The fringe, I think.
>
> The fringe nearest the scroll-bar is the right place to display the
> indicators I think, but we need a new mechanism to display them, as they
> should not scroll with the buffer text.

Does this mean an additional fringe is necessary that doesn't scroll?

Then we have the same question as with multiple header lines:
whether to allow multiple fringes and header lines or implement them
as true windows placed on the left or on the top of the base window.

Using windows will allow implementing emulations of the scroll bar
like minimap.el, etc.  I'm not sure whether this is possible to do
with additional fringes?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Side windows

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  grishka@gmx.de,  drew.adams@oracle.com,  emacs-devel@gnu.org
> Date: Wed, 14 Apr 2010 19:52:01 +0300
> 
> >>>   ** Compilation error navigation bar, parallel to the scroll bar,
> >>>   indicating where in the buffer there are compilation errors.
> >>>   Perhaps we could arrange to display these error indications on top
> >>>   of the scroll bar itself.  That depends on to what extent toolkit
> >>>   scroll bars are extensible.
> >>>
> >>> If it's possible to display such tab-like indications
> >>> on the scroll bar, is it still called a scroll bar?
> >>>
> >>> If it's not possible, then what is an alternative?
> >>> Maybe, 1-column side bar windows?
> >>
> >> The fringe, I think.
> >
> > The fringe nearest the scroll-bar is the right place to display the
> > indicators I think, but we need a new mechanism to display them, as they
> > should not scroll with the buffer text.
> 
> Does this mean an additional fringe is necessary that doesn't scroll?

Not necessarily.  We could provide a feature whereby bitmaps displayed
in the fringe would be moved by redisplay so that their position
relative to the window top does not change as the window is scrolled.

Re: Side windows

[Juri Linkov]

>> >>> Maybe, 1-column side bar windows?
>> >>
>> >> The fringe, I think.
>> >
>> > The fringe nearest the scroll-bar is the right place to display the
>> > indicators I think, but we need a new mechanism to display them, as
>> > they should not scroll with the buffer text.
>>
>> Does this mean an additional fringe is necessary that doesn't scroll?
>
> Not necessarily.  We could provide a feature whereby bitmaps displayed
> in the fringe would be moved by redisplay so that their position
> relative to the window top does not change as the window is scrolled.

Currently fringe positions are relative to lines (to indicate truncated
lines, continued lines, overlay arrows, etc.)

Using it to indicate window relative positions like scroll bars do
will make a mess in the same fringe.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Side windows

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: jasonr@gnu.org,  grishka@gmx.de,  drew.adams@oracle.com,  emacs-devel@gnu.org
> Date: Thu, 15 Apr 2010 02:54:21 +0300
> 
> Currently fringe positions are relative to lines (to indicate truncated
> lines, continued lines, overlay arrows, etc.)
> 
> Using it to indicate window relative positions like scroll bars do
> will make a mess in the same fringe.

The proposed bitmap is very small (thin), AFAIU, so I'm not sure the
mess would be quite as big as you seem to fear.  Overlay arrows are on
the left fringe, so they do not contribute to the mess at all.  We
could enlarge the right fringe (in compilation-mode) to make the mess
even smaller.

An alternative could be to use the margin for this.  Its advantage is
that it will also work on a TTY.  But I think this would be a larger
job because currently margins are not clickable, while the fringe is.

Re: Side windows

[Juri Linkov]

> The proposed bitmap is very small (thin), AFAIU, so I'm not sure the
> mess would be quite as big as you seem to fear.  Overlay arrows are on
> the left fringe, so they do not contribute to the mess at all.  We
> could enlarge the right fringe (in compilation-mode) to make the mess
> even smaller.

This practically means multi-column fringes.  Maybe the same suggests
implementing the multi-line header line instead of multiple header lines
or multiple header windows.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Side windows

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: jasonr@gnu.org,  grishka@gmx.de,  drew.adams@oracle.com,  emacs-devel@gnu.org
> Date: Fri, 16 Apr 2010 02:46:17 +0300
> 
> > The proposed bitmap is very small (thin), AFAIU, so I'm not sure the
> > mess would be quite as big as you seem to fear.  Overlay arrows are on
> > the left fringe, so they do not contribute to the mess at all.  We
> > could enlarge the right fringe (in compilation-mode) to make the mess
> > even smaller.
> 
> This practically means multi-column fringes.

No, it doesn't.  I wasn't suggesting to have more than one bitmap on
the fringe at the same place (I think this is impossible with today's
code).  I was just saying that the visual appearance would not be as
bad as it may sound.

> Maybe the same suggests implementing the multi-line header line
> instead of multiple header lines or multiple header windows.

I don't think so.  The current display engine does not support a
notion of glyph rows that are more than one glyph tall.  And since
each glyph comes from some font, you cannot have two of them together,
unless you either (a) craft a font with combination of 2 characters in
it, or (b) make some composition rules to compose them into a single
glyph.

Re: Side windows

[Jan Djärv]

Juri Linkov skrev 2010-04-14 01.31:
>> To give another example:  A scrollbar is defined mostly by its action
>> to "scroll content in the associated window".  Of course you could use
>> the scrollbar widget just as well to adjust your speaker volume, but
>> then it wouldn't be a scrollbar, even if it looked like one.
>
> There is a task in etc/TODO:
>
>    ** Compilation error navigation bar, parallel to the scroll bar,
>    indicating where in the buffer there are compilation errors.
>    Perhaps we could arrange to display these error indications on top
>    of the scroll bar itself.  That depends on to what extent toolkit
>    scroll bars are extensible.
>
> If it's possible to display such tab-like indications
> on the scroll bar, is it still called a scroll bar?
>
> If it's not possible, then what is an alternative?
> Maybe, 1-column side bar windows?
>

As Eli already said, the fringe.  Scrollbars aren't the place for this.
How do you know when to remove these indications?

	Jan D.

Re: Side windows

[grischka]

[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

Juri Linkov wrote:
> There is a task in etc/TODO:
> 
>   ** Compilation error navigation bar, parallel to the scroll bar,
>   indicating where in the buffer there are compilation errors.
>   Perhaps we could arrange to display these error indications on top
>   of the scroll bar itself.  That depends on to what extent toolkit
>   scroll bars are extensible.
> 
> If it's possible to display such tab-like indications
> on the scroll bar, is it still called a scroll bar?
> 
> If it's not possible, then what is an alternative?
> Maybe, 1-column side bar windows?

WinMerge and KDiff3 have a "sort of" scrollbar with transparent thumb
used to indicate (and jump to) the regions with differences.

See picture.

[-- Attachment #2: wmind.png --]
[-- Type: image/png, Size: 4270 bytes --]

Re: Side windows

[Juri Linkov]

>>   ** Compilation error navigation bar, parallel to the scroll bar,
>>   indicating where in the buffer there are compilation errors.
>>   Perhaps we could arrange to display these error indications on top
>>   of the scroll bar itself.  That depends on to what extent toolkit
>>   scroll bars are extensible.
>>
>> If it's possible to display such tab-like indications
>> on the scroll bar, is it still called a scroll bar?
>>
>> If it's not possible, then what is an alternative?
>> Maybe, 1-column side bar windows?
>
> WinMerge and KDiff3 have a "sort of" scrollbar with transparent thumb
> used to indicate (and jump to) the regions with differences.
>
> See picture.

This is definitely impossible to do in fringes with today's code.
But using the same technique as is used by palette.el
http://www.emacswiki.org/emacs/ColorPalette to create pseudo-graphics
in a side window it should be doable.

-- 
Juri Linkov
http://www.jurta.org/emacs/