Re: just-the-text Emacs frame

Re: just-the-text Emacs frame

[T. V. Raman]

Havent seen stumpwm mentioned on this thread --- I switched to
xmonad a couple of weeks ago but never having written haskell
went looking further -- stumpwm sounded interesting because it's
written in Common Lisp and appears to have some emacs
integration. Googling also threw up the xioemacs project that
appears to have stalled -- 

-- 
Best Regards,
--raman

-- 
Best Regards,
--raman

Emacs as a desktop environment

[Ted Zlatanov]

I've been very frustrated lately with the memory and resource use of
gnome-panel, XFCE, and the new Unity UI in Ubuntu 11.04.  They use
multiple megabytes of memory for trivial things; they are slow, and they
make a machine with 3 GB of RAM feel slow just doing trivial things.

I think GNU Emacs, at least on GNU/Linux systems, can provide much of
the desktop environment functionality, so Emacs + a window manager like
XMonad is a full desktop experience:

- launch bar: a place to put icons associated with a program (simple toolbar)

- Applications, Places, and System menus: not sure how to connect those

- load indicators (CPU, memory, network load, etc.): can be done with SVG

- date, weather, market indicators: SVG and/or plain text

- workspace indicator: needs to talk to the window manager

- all file management: Dired

- icon dock for application and system indicators

I'd like to know how much of this can be achieved with today's GNU Emacs
plus the external packages (GNU ELPA, Tom Tromey's ELPA, EmacsWiki,
etc.) available, and how much will require new packages or changes to
Emacs' internals.

Thanks
Ted

Re: Emacs as a desktop environment

[Eric M. Ludlam]

As a part of Emacsifying your desktop, there is XWEM, which puts your 
emacs into a window manager implemented in Emacs.  If I recall, you can 
put some regular X widgets in the tray to get the time and battery and a 
few other things.

http://www.nongnu.org/xwem/

Eric

On 05/24/2011 09:05 PM, Ted Zlatanov wrote:
> I've been very frustrated lately with the memory and resource use of
> gnome-panel, XFCE, and the new Unity UI in Ubuntu 11.04.  They use
> multiple megabytes of memory for trivial things; they are slow, and they
> make a machine with 3 GB of RAM feel slow just doing trivial things.
>
> I think GNU Emacs, at least on GNU/Linux systems, can provide much of
> the desktop environment functionality, so Emacs + a window manager like
> XMonad is a full desktop experience:
>
> - launch bar: a place to put icons associated with a program (simple toolbar)
>
> - Applications, Places, and System menus: not sure how to connect those
>
> - load indicators (CPU, memory, network load, etc.): can be done with SVG
>
> - date, weather, market indicators: SVG and/or plain text
>
> - workspace indicator: needs to talk to the window manager
>
> - all file management: Dired
>
> - icon dock for application and system indicators
>
> I'd like to know how much of this can be achieved with today's GNU Emacs
> plus the external packages (GNU ELPA, Tom Tromey's ELPA, EmacsWiki,
> etc.) available, and how much will require new packages or changes to
> Emacs' internals.
>
> Thanks
> Ted
>
>
>

Re: Emacs as a desktop environment

[Ted Zlatanov]

On Wed, 25 May 2011 20:58:15 -0400 "Eric M. Ludlam" <eric@siege-engine.com> wrote: 

EML> As a part of Emacsifying your desktop, there is XWEM, which puts your
EML> emacs into a window manager implemented in Emacs.  If I recall, you
EML> can put some regular X widgets in the tray to get the time and battery
EML> and a few other things.

EML> http://www.nongnu.org/xwem/

I looked at it and it looks abandoned, plus the window manager is the
one piece that doesn't need to replaced in my view.

On Wed, 25 May 2011 19:33:11 -0600 Tom Tromey <tromey@redhat.com> wrote: 

Tom> I have a hack to put things in the system tray from Emacs.
Tom> It isn't very well done; it would be nice if Emacs could do this, too.
Tom> Maybe this is related to what you are interested in, but maybe not.. ?

No, that's going the other way.  I want an Emacs instance to *be* the
system tray (and workspace indicator, and basically everything that
makes a desktop environment except the window manager and the
applications themselves).  Can the system tray interface be implemented
as a protocol or does it need C code?

Thanks
Ted

Re: Emacs as a desktop environment

[joakim]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Wed, 25 May 2011 20:58:15 -0400 "Eric M. Ludlam" <eric@siege-engine.com> wrote: 
>
> EML> As a part of Emacsifying your desktop, there is XWEM, which puts your
> EML> emacs into a window manager implemented in Emacs.  If I recall, you
> EML> can put some regular X widgets in the tray to get the time and battery
> EML> and a few other things.
>
> EML> http://www.nongnu.org/xwem/
>
> I looked at it and it looks abandoned, plus the window manager is the
> one piece that doesn't need to replaced in my view.
>
> On Wed, 25 May 2011 19:33:11 -0600 Tom Tromey <tromey@redhat.com> wrote: 
>
> Tom> I have a hack to put things in the system tray from Emacs.
> Tom> It isn't very well done; it would be nice if Emacs could do this, too.
> Tom> Maybe this is related to what you are interested in, but maybe not.. ?
>
> No, that's going the other way.  I want an Emacs instance to *be* the
> system tray (and workspace indicator, and basically everything that
> makes a desktop environment except the window manager and the
> applications themselves).  Can the system tray interface be implemented
> as a protocol or does it need C code?

I'm not really sure what you mean but I think most things can be done
using dbus. If you mean actualy docking the applets inside Emacs that
can't be done yet. OTOH it is interesting to note that the trend, as
illustrated by Gnome 3, is to remove nearly everything from the desktop.

My approach is to run Emacs in fullscreen, using zen-mode on
github. When I want to know the time or network connectivity or
something I press F5 to bring up a temporary Emacs buffer with that
information. That way I can supposedly concentrate on work rather than
staring at the clock. I solved the need for a system load meter by
getting a faster laptop...

>
> Thanks
> Ted
>

-- 
Joakim Verona

Re: Emacs as a desktop environment

[Ted Zlatanov]

On Thu, 26 May 2011 18:38:16 +0200 joakim@verona.se wrote: 

j> When I want to know the time or network connectivity or something I
j> press F5 to bring up a temporary Emacs buffer with that
j> information. That way I can supposedly concentrate on work rather
j> than staring at the clock.

Can you show the code you use for F5?

Ted

Re: Emacs as a desktop environment

[joakim]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 26 May 2011 18:38:16 +0200 joakim@verona.se wrote: 
>
> j> When I want to know the time or network connectivity or something I
> j> press F5 to bring up a temporary Emacs buffer with that
> j> information. That way I can supposedly concentrate on work rather
> j> than staring at the clock.
>
> Can you show the code you use for F5?

(require 'battery)
(require 'timeclock)
(defun modeline-depopulator ()
  (interactive)
  (message "%s\n%s\n%s\n%s"
           (format-time-string "%H:%M %Y-%m-%d" (current-time))
           (battery-format battery-echo-area-format (funcall
                                                     battery-status-function))
           (timeclock-status-string)
           (shell-command-to-string "nmcli -p dev")

           ))
(global-set-key [f5] 'modeline-depopulator)


>
> Ted
>

-- 
Joakim Verona

just-the-text Emacs frame (was: Emacs as a desktop environment)

[Ted Zlatanov]

I just want to display some text, nothing else.  How about this (based
on your code) to show some arbitrary text in a popup (no menus,
modeline, etc., just the buffer is visible)?  I think it will DTRT
whether the frame is shown already or not.  I can use this to show the
indicators, icons, and status messages.

#+begin_src lisp
(require 'battery)
(require 'timeclock)

(defvar popup-info-frame)

(defun popup-info-string ()
  (format "%s\n%s\n%s\n%s"
          (format-time-string "%H:%M %Y-%m-%d" (current-time))
          (battery-format battery-echo-area-format (funcall
                                                    battery-status-function))
          (timeclock-status-string)
          (shell-command-to-string "nmcli -p dev")))

(defun popup-info ()
  (interactive)
  (popup-info--1 " *popup status*"))

(defun popup-info--1 (bufname)
  (with-current-buffer (get-buffer-create bufname)
    (make-local-variable 'popup-info-frame)
    (if (and (boundp 'popup-info-frame)
             popup-info-frame
             (member popup-info-frame (frame-list)))
        (select-frame popup-info-frame)
      (let ((default-frame-alist '((minibuffer . nil)
                                   (width . 20)
                                   (border-width . 0)
                                   (menu-bar-lines . 0)
                                   (tool-bar-lines . 0)
                                   (unsplittable . t)
                                   (left-fringe . 0))))
        (switch-to-buffer-other-frame bufname)
        (setq popup-info-frame (selected-frame))))
    (erase-buffer)
    (setq mode-line-format nil)
    (redraw-modeline)
    (insert (popup-info-string))))

#+end_src

Let me know what you think.  It supports any number of status buffers by
name and behaves correctly even if the frame is closed.

Thanks!
Ted

Re: just-the-text Emacs frame

[Thierry Volpiatto]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I just want to display some text, nothing else.  How about this (based

Do you know popup.el? (you should find it on emacswiki in auto-complete).

--8<---------------cut here---------------start------------->8---
(require 'popup)

(defun popup-info-string ()
  (format "%s\n%s\n%s\n%s"
          (format-time-string "%H:%M %Y-%m-%d" (current-time))
          (battery-format battery-echo-area-format (funcall
                                                    battery-status-function))
          (timeclock-status-string)
          (shell-command-to-string "nmcli -p dev")))

(popup-tip (popup-info-string))
--8<---------------cut here---------------end--------------->8---

> on your code) to show some arbitrary text in a popup (no menus,
> modeline, etc., just the buffer is visible)?  I think it will DTRT
> whether the frame is shown already or not.  I can use this to show the
> indicators, icons, and status messages.
>
> #+begin_src lisp
> (require 'battery)
> (require 'timeclock)
>
> (defvar popup-info-frame)
>
> (defun popup-info-string ()
>   (format "%s\n%s\n%s\n%s"
>           (format-time-string "%H:%M %Y-%m-%d" (current-time))
>           (battery-format battery-echo-area-format (funcall
>                                                     battery-status-function))
>           (timeclock-status-string)
>           (shell-command-to-string "nmcli -p dev")))
>
> (defun popup-info ()
>   (interactive)
>   (popup-info--1 " *popup status*"))
>
> (defun popup-info--1 (bufname)
>   (with-current-buffer (get-buffer-create bufname)
>     (make-local-variable 'popup-info-frame)
>     (if (and (boundp 'popup-info-frame)
>              popup-info-frame
>              (member popup-info-frame (frame-list)))
>         (select-frame popup-info-frame)
>       (let ((default-frame-alist '((minibuffer . nil)
>                                    (width . 20)
>                                    (border-width . 0)
>                                    (menu-bar-lines . 0)
>                                    (tool-bar-lines . 0)
>                                    (unsplittable . t)
>                                    (left-fringe . 0))))
>         (switch-to-buffer-other-frame bufname)
>         (setq popup-info-frame (selected-frame))))
>     (erase-buffer)
>     (setq mode-line-format nil)
>     (redraw-modeline)
>     (insert (popup-info-string))))
>
> #+end_src
>
> Let me know what you think.  It supports any number of status buffers by
> name and behaves correctly even if the frame is closed.
>
> Thanks!
> Ted
>
>
>

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Sat, 28 May 2011 22:18:14 +0200 Thierry Volpiatto <thierry.volpiatto@gmail.com> wrote: 

TV> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I just want to display some text, nothing else.  How about this (based

TV> Do you know popup.el? (you should find it on emacswiki in auto-complete).
TV> (require 'popup)
...
TV> (popup-tip (popup-info-string))

I think a standalone frame (note all the details in my code that make it
as bare as possible) is more useful, but I'll keep this in mind as well.

Thanks
Ted

Re: just-the-text Emacs frame

[joakim]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>> I just want to display some text, nothing else.  How about this (based
>
> Do you know popup.el? (you should find it on emacswiki in auto-complete).

I tried this and it was nice. I use a fullscreen Emacs ond the popup
lets me not move the focus from where I am in the buffer. I will try
Teds frame solution next.

>
> (require 'popup)
>
> (defun popup-info-string ()
>   (format "%s\n%s\n%s\n%s"
>           (format-time-string "%H:%M %Y-%m-%d" (current-time))
>           (battery-format battery-echo-area-format (funcall
>                                                     battery-status-function))
>           (timeclock-status-string)
>           (shell-command-to-string "nmcli -p dev")))
>
> (popup-tip (popup-info-string))
>
>> on your code) to show some arbitrary text in a popup (no menus,
>> modeline, etc., just the buffer is visible)?  I think it will DTRT
>> whether the frame is shown already or not.  I can use this to show the
>> indicators, icons, and status messages.
>>
>> #+begin_src lisp
>> (require 'battery)
>> (require 'timeclock)
>>
>> (defvar popup-info-frame)
>>
>> (defun popup-info-string ()
>>   (format "%s\n%s\n%s\n%s"
>>           (format-time-string "%H:%M %Y-%m-%d" (current-time))
>>           (battery-format battery-echo-area-format (funcall
>>                                                     battery-status-function))
>>           (timeclock-status-string)
>>           (shell-command-to-string "nmcli -p dev")))
>>
>> (defun popup-info ()
>>   (interactive)
>>   (popup-info--1 " *popup status*"))
>>
>> (defun popup-info--1 (bufname)
>>   (with-current-buffer (get-buffer-create bufname)
>>     (make-local-variable 'popup-info-frame)
>>     (if (and (boundp 'popup-info-frame)
>>              popup-info-frame
>>              (member popup-info-frame (frame-list)))
>>         (select-frame popup-info-frame)
>>       (let ((default-frame-alist '((minibuffer . nil)
>>                                    (width . 20)
>>                                    (border-width . 0)
>>                                    (menu-bar-lines . 0)
>>                                    (tool-bar-lines . 0)
>>                                    (unsplittable . t)
>>                                    (left-fringe . 0))))
>>         (switch-to-buffer-other-frame bufname)
>>         (setq popup-info-frame (selected-frame))))
>>     (erase-buffer)
>>     (setq mode-line-format nil)
>>     (redraw-modeline)
>>     (insert (popup-info-string))))
>>
>> #+end_src
>>
>> Let me know what you think.  It supports any number of status buffers by
>> name and behaves correctly even if the frame is closed.
>>
>> Thanks!
>> Ted
>>
>>
>>

-- 
Joakim Verona

Re: just-the-text Emacs frame

[Ted Zlatanov]

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

On Sat, 28 May 2011 12:49:59 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> I just want to display some text, nothing else.  How about this (based
TZ> on your code) to show some arbitrary text in a popup (no menus,
TZ> modeline, etc., just the buffer is visible)?  I think it will DTRT
TZ> whether the frame is shown already or not.  I can use this to show the
TZ> indicators, icons, and status messages.

Attached is emacs-panel.el, which does the above.  It support arbitrary
frames, each one showing a specific buffer and refreshing its content on
a timer with a function associated with that buffer.

There's an example in the commentary that shows how it's used.  It works
for me.  Let me know what you think; next I will start adding pieces to
this framework to implement each of the tasks I listed earlier.

Thanks
Ted


[-- Attachment #2: emacs-panel.el --]
[-- Type: application/emacs-lisp, Size: 4268 bytes --]

Re: just-the-text Emacs frame

[Leo]

On 2011-06-02 02:01 +0800, Ted Zlatanov wrote:
> Attached is emacs-panel.el, which does the above.  It support arbitrary
> frames, each one showing a specific buffer and refreshing its content on
> a timer with a function associated with that buffer.
>
> There's an example in the commentary that shows how it's used.  It works
> for me.  Let me know what you think; next I will start adding pieces to
> this framework to implement each of the tasks I listed earlier.
>
> Thanks
> Ted

Can this pop up a frame without a title bar, much like what tooltip
does?

Leo

Re: just-the-text Emacs frame

[Eli Zaretskii]

> From: Leo <sdl.web@gmail.com>
> Date: Thu, 02 Jun 2011 10:43:35 +0800
> 
> Can this pop up a frame without a title bar, much like what tooltip
> does?

Not without some help from the display engine on the C level, AFAICT.
Tooltips are special kind of frame treated specially by redisplay.

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Thu, 02 Jun 2011 00:05:28 -0400 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Leo <sdl.web@gmail.com>
>> Date: Thu, 02 Jun 2011 10:43:35 +0800
>> 
>> Can this pop up a frame without a title bar, much like what tooltip
>> does?

EZ> Not without some help from the display engine on the C level, AFAICT.
EZ> Tooltips are special kind of frame treated specially by redisplay.

I always thought frame decorations came from the window manager; is
there a way to tell it "I draw my own title bar"?  I think Google Chrome
does that.  If there's a frame property we can add at the C level to
hint this, it would make emacs-panel popups better and probably be nice
for Emacs in general.

I wouldn't go as far as a tooltip, though.  I think it's important that
the emacs-panel popup frames be like any other Emacs frame, simply
displaying a buffer.  That way we can use all the normal buffer-level
facilities when we display things inside emacs-panel popups, like text
properties and image overlays and UI elements.

Ted

Re: just-the-text Emacs frame

[Mohsen BANAN]

>>>>> On Thu, 02 Jun 2011 08:15:31 -0500, Ted Zlatanov <tzz@lifelogs.com> said:

  Ted> I wouldn't go as far as a tooltip, though.  I think it's important that
  Ted> the emacs-panel popup frames be like any other Emacs frame, simply
  Ted> displaying a buffer.  That way we can use all the normal buffer-level
  Ted> facilities when we display things inside emacs-panel popups, like text
  Ted> properties and image overlays and UI elements.

I request for a bit more inside of an emacs-panel.

Please let live emacs-panels consist of live emacs-tiles.

Live meaning updated (as you are already doing it
with the timer).

A live emacs-tile being a rectangle. Associated
with a buffer.

Each emacs-tile has an "update" function.

A live emacs-tile may optionally have a clickable
(touchable) function. So, in addition to being
"live" it is optionally "active". Each emacs-tile
may have an "activate" function.

So, an emacs-panel would not be simply displaying
a buffer, but possibly a series of buffers
(tiles).

With tiles available inside of panels, we would be
one more step closer towards making Emacs24 Mobile.

With "live" and "active" emacs-tiles available within
emacs-panels, we could then provide a parallel to
(easy-menu-define) where even existing menus are also
emacs-panel/tile based.

The process of splitting an emacs-panel into
emacs-tiles can be based on something like Lars's
(gnus-add-configuration).

All of that would let Emacs24-Mobile to compete
with Windows7-Mobile UI.

Your thoughts?

...Mohsen

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Thu, 02 Jun 2011 08:43:55 -0700 Mohsen BANAN <list-general@mohsen.1.banan.byname.net> wrote: 

>>>>>> On Thu, 02 Jun 2011 08:15:31 -0500, Ted Zlatanov <tzz@lifelogs.com> said:

Ted> I wouldn't go as far as a tooltip, though.  I think it's important that
Ted> the emacs-panel popup frames be like any other Emacs frame, simply
Ted> displaying a buffer.  That way we can use all the normal buffer-level
Ted> facilities when we display things inside emacs-panel popups, like text
Ted> properties and image overlays and UI elements.

MB> I request for a bit more inside of an emacs-panel.

MB> Please let live emacs-panels consist of live emacs-tiles.
...
MB> So, an emacs-panel would not be simply displaying a buffer, but
MB> possibly a series of buffers (tiles).

Should those tiles be Emacs windows or buffer-level facilities?

At the buffer level we can manage and decorate them better, but the
Emacs windows may have advantages too.  I can't think of any for this
case.

MB> Each emacs-tile has an "update" function.

OK.

MB> A live emacs-tile may optionally have a clickable (touchable)
MB> function. So, in addition to being "live" it is optionally
MB> "active". Each emacs-tile may have an "activate" function.

That should be a property of the text produced by the "update" function.

MB> With "live" and "active" emacs-tiles available within emacs-panels,
MB> we could then provide a parallel to (easy-menu-define) where even
MB> existing menus are also emacs-panel/tile based.

MB> The process of splitting an emacs-panel into emacs-tiles can be
MB> based on something like Lars's (gnus-add-configuration).

Can you provide an example?  I don't know exactly what you mean here.

Thanks
Ted

Re: just-the-text Emacs frame

[Mohsen BANAN]

>>>>> On Thu, 02 Jun 2011 12:41:25 -0500, Ted Zlatanov <tzz@lifelogs.com> said:
  Ted> On Thu, 02 Jun 2011 08:43:55 -0700 Mohsen BANAN <list-general@mohsen.1.banan.byname.net> wrote: 
  >>>>>>> On Thu, 02 Jun 2011 08:15:31 -0500, Ted Zlatanov <tzz@lifelogs.com> said:


  MB> Please let live emacs-panels consist of live emacs-tiles.
  Ted> ...
  MB> So, an emacs-panel would not be simply displaying a buffer, but
  MB> possibly a series of buffers (tiles).

  Ted> Should those tiles be Emacs windows or buffer-level facilities?

I wrote that poorly.

Usually not emacs windows.

In the concrete, emacs-panel would be simply
displaying a buffer but in the abstract the
emacs-panel buffer is the aggregation of a series
of emacs-tiles (likely buffers). 

I'll be expanding on this in the context of an
example below.

  MB> A live emacs-tile may optionally have a clickable (touchable)
  MB> function. So, in addition to being "live" it is optionally
  MB> "active". Each emacs-tile may have an "activate" function.

  Ted> That should be a property of the text produced by the "update" function.

Possible to do it that way but there are also
advantages for an entire emacs-tile to be declared
active to the emacs-panel. 

More on this in the example below.


  MB> The process of splitting an emacs-panel into emacs-tiles can be
  MB> based on something like Lars's (gnus-add-configuration).

  Ted> Can you provide an example?  I don't know exactly what you mean here.

Gnus provides a facility for structuring a frame
into multiple windows based on horizontal/vertical
box specifications.

On a wide screen, mine is this:

(defun bystar:mail:display:frame-wide ()
  "On a Wide Frame"
  (interactive)

  (gnus-add-configuration
   '(summary
     (horizontal 1.0
		 (vertical 0.6 (summary 1.0 point))
		 (vertical 1.0 (group 1.0)))))

  (gnus-add-configuration
   '(article
     (horizontal 1.0
		 (vertical 0.6 (summary 0.25 point) (article 1.0) )
		 (vertical 1.0  ("*BBDB*" 1.0) (score-trace 0.1)))))
  )

So, I am proposing that similarly an emacs-panel can be
devided into emacs-tiles.

The example below explains it more.

Panel of Tiles Example:
-----------------------

Consider that we were trying to mimic what 
Windows 7 Mobile is doing in:
  
  http://www.blogcdn.com/www.engadget.com/media/2010/02/02-15-10winphone2.jpg

There will be 1 emacs-panel containing 7
emacs-tiles.

So, we need to:

    - Specify 7 emacs-tiles. (6 squares 1 rectangle
      in that picture.)
    - Specify lay out and sizes of the tiles within the
      panel. Based on something similar to gnus-add-configuration.
    - Specify the emacs-panel's overall size ... and
      make it contain the 7 emacs-tiles.

As you said, a tile in a panel is not same as a 
window in a frame.

The horizontal/vertical dividers for the tiles
could be as simple as lines (thin dividers -- not scroll bars).

I have a preference for the "active" abstraction
for the entire tile to be optionally deligated to
the panel manager as opposed to always being a
property of the text inside of the tile.

The idea is that on a handset you would always
take it for granted that touching (clicking) a
tile will always do something. 

My motivation is to facilitate getting things
started towards Emacs Mobile. The maping between
the container of a set of tiles into a panel can
be at frame or window level. May be we need a
separate abstraction name for the container of a
set of tiles.

With something like this (panels of tiles) in
place, emacs can quickly be made quite usable on a
touch based handset.

On a large screen, outside of the handset usage,
using you own example:

(emacs-panel-popup-add
 "status" :function
 (lambda ()
   (format "%s\n%s\n%s\n%s"
           (format-time-string "%H:%M %Y-%m-%d" (current-time))
           (battery-format battery-echo-area-format (funcall
                                                     battery-status-function))
           (timeclock-status-string)
           (shell-command-to-string "nmcli -p  dev"))))

Using tiles, you could be creating 4 tiles for 
each of:

           (format-time-string "%H:%M %Y-%m-%d" (current-time))

           (battery-format battery-echo-area-format (funcall
                                                     battery-status-function))

           (timeclock-status-string)

           (shell-command-to-string "nmcli -p  dev")

With tile dividers between them and separate
update functions ...

What do you think?

Thanks.

...Mohsen

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Thu, 02 Jun 2011 13:19:49 -0700 Mohsen BANAN <list-general@mohsen.1.banan.byname.net> wrote: 

MB> Panel of Tiles Example:
MB> -----------------------

MB> Consider that we were trying to mimic what 
MB> Windows 7 Mobile is doing in:
  
MB>   http://www.blogcdn.com/www.engadget.com/media/2010/02/02-15-10winphone2.jpg

I'll reply to the rest later, but please let's not try to mimic
anything.  If we create something, let it be the right fit for our
needs, not a rehash of other people's ideas.  These tiles are just large
buttons with HTML and other dynamic content, aren't they?  Emacs can do
it 100x better, and we don't need kinetic scolling or visual candy to
make it useful.

I bring this up here because emacs-panel.el is intended to fix some of
the things I dislike about Gnome and other desktop environments,
especially how they mimic the Windows and Mac OS X desktop environments
and how expensive their resource usage is.  So I hope you will agree.

Thanks
Ted

Re: just-the-text Emacs frame

[Mohsen BANAN]

>>>>> On Thu, 02 Jun 2011 16:06:22 -0500, Ted Zlatanov <tzz@lifelogs.com> said:

  Ted> On Thu, 02 Jun 2011 13:19:49 -0700 Mohsen BANAN <list-general@mohsen.1.banan.byname.net> wrote: 
  MB> Panel of Tiles Example:
  MB> -----------------------

  MB> Consider that we were trying to mimic what 
  MB> Windows 7 Mobile is doing in:
  
  MB> http://www.blogcdn.com/www.engadget.com/media/2010/02/02-15-10winphone2.jpg

  Ted> I'll reply to the rest later, but please let's not try to mimic
  Ted> anything.  If we create something, let it be the right fit for our
  Ted> needs, not a rehash of other people's ideas.  These tiles are just large
  Ted> buttons with HTML and other dynamic content, aren't they?  Emacs can do
  Ted> it 100x better, and we don't need kinetic scolling or visual candy to
  Ted> make it useful.

  Ted> I bring this up here because emacs-panel.el is intended to fix some of
  Ted> the things I dislike about Gnome and other desktop environments,
  Ted> especially how they mimic the Windows and Mac OS X desktop environments
  Ted> and how expensive their resource usage is.  So I hope you will agree.

My goal has been to add considerations for emacs
on handsets (small screen + touch) into the mix.

In that context I am convinced that tiles, larger
buttons, keypads and full screen menus have a
place towards adapting emacs to handsets.

This does not mean that we should abandon the
emacs paradigm and mimic the iPhone/Android/WinMob/...
paradigms. 

So, I am proposing experimentation with the following
hierarchy:

  - Bare-Frames (no mini-buf, no menu, ...)
     - Related Windows
        - Panels (Collection of Tiles)
           - Tiles (Optionally Live and Active)

If such facilities were in place, I think we could
move towards making emacs more usable on a
handset.

The purpose of my citing the Windows 7 Mobile
screen was to point applicability of the above to
a common full screen menu model.

Let's now throw Microsoft Windows 7 Mobile
completely out of the picture.

Consider use of emacs's calc on a handset.

In that case, the prefered UI is likely :
(calc-keypad)

The basic structure of (calc-keypad) is:

  - 2 related windows in the current frame.
  - A custom made text grid functioning as a keypad

In this case, I am saying let's add to emacs
necessary abstraction and facilities so that:

  - The two related windows can fit properly in a
    Bare-Frame without any waste of screen space
    on the handset.

  - Instead of a custom made grid functioning as a
    keypad let's provide tiles such that keypads 
    are done nicer and better.

If these ideas fit in the direction that you are
headed, please consider my requests.

Thanks.

...Mohsen

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Thu, 02 Jun 2011 13:19:49 -0700 Mohsen BANAN <list-general@mohsen.1.banan.byname.net> wrote: 

MB> Gnus provides a facility for structuring a frame
MB> into multiple windows based on horizontal/vertical
MB> box specifications.
...
MB>   (gnus-add-configuration
MB>    '(summary
MB>      (horizontal 1.0
MB> 		 (vertical 0.6 (summary 1.0 point))
MB> 		 (vertical 1.0 (group 1.0)))))

Oh right, so it's a tree of H and V splits.

MB> So, I am proposing that similarly an emacs-panel can be
MB> devided into emacs-tiles.

OK.

MB>     - Specify 7 emacs-tiles. (6 squares 1 rectangle
MB>       in that picture.)
MB>     - Specify lay out and sizes of the tiles within the
MB>       panel. Based on something similar to gnus-add-configuration.
MB>     - Specify the emacs-panel's overall size ... and
MB>       make it contain the 7 emacs-tiles.

MB> The horizontal/vertical dividers for the tiles
MB> could be as simple as lines (thin dividers -- not scroll bars).

There is no need for dividers.  Just set the background to a different
color and give each tile a little padding or margin.

MB> I have a preference for the "active" abstraction for the entire tile
MB> to be optionally deligated to the panel manager as opposed to always
MB> being a property of the text inside of the tile.

Maybe we can write a tiling panel manager, then, which can run inside
any buffer and tile any content using the configurations you showed.
That would be generally useful, not just for mobile devices.

MB> My motivation is to facilitate getting things started towards Emacs
MB> Mobile. The maping between the container of a set of tiles into a
MB> panel can be at frame or window level. May be we need a separate
MB> abstraction name for the container of a set of tiles.

It would be simplest to call tiles by name (symbol or string) and nest
them inside frames (always using just one buffer per frame).  So you'd
define a tile with margin, padding, etc. properties:

(emacs-panel-tile-add "myfeeds" :margin 3 :text ... :call ...)
(emacs-panel-tile-add 'mychat :padding 2 :update-function ... :call ...)

and then use it in a tiled 3x3 layout:

(emacs-panel-popup-add "status" :tiles '(nil "myfeeds" nil 'mychat)
                                :background "black"
                                :layout-manager '(tile :x 3 :y 3))

Does that API seem OK?  Or do you still think a H/V split tree is needed
and we should support irregular grids?  Remember, they are more powerful
but also harder to use and configure...  So maybe we should start with
simple tiling and add irregular grids later.

On Fri, 03 Jun 2011 08:09:39 -0700 Mohsen BANAN <list-general@mohsen.1.banan.byname.net> wrote: 

MB> So, I am proposing experimentation with the following
MB> hierarchy:

MB>   - Bare-Frames (no mini-buf, no menu, ...)
MB>      - Related Windows
MB>         - Panels (Collection of Tiles)
MB>            - Tiles (Optionally Live and Active)

Yes.  We're at bare frames now, slowly moving towards panels and tiles.
I think a panel should be a frame.  I'm not sure what related windows
are.

MB> Consider use of emacs's calc on a handset.

Your example is useful, but you're jumping too far ahead.  Let's work on
the general panel and tiling functionality first.

Ted

Re: just-the-text Emacs frame

[Mohsen BANAN]

>>>>> On Fri, 03 Jun 2011 15:56:20 -0500, Ted Zlatanov <tzz@lifelogs.com> said:

  Ted> It would be simplest to call tiles by name (symbol or string) and nest
  Ted> them inside frames (always using just one buffer per frame).  So you'd
  Ted> define a tile with margin, padding, etc. properties:

  Ted> (emacs-panel-tile-add "myfeeds" :margin 3 :text ... :call ...)
  Ted> (emacs-panel-tile-add 'mychat :padding 2 :update-function ... :call ...)

  Ted> and then use it in a tiled 3x3 layout:

  Ted> (emacs-panel-popup-add "status" :tiles '(nil "myfeeds" nil 'mychat)
  Ted>                                 :background "black"
  Ted>                                 :layout-manager '(tile :x 3 :y 3))

  Ted> Does that API seem OK?  Or do you still
  Ted> think a H/V split tree is needed and we
  Ted> should support irregular grids?  Remember,
  Ted> they are more powerful but also harder to
  Ted> use and configure...  So maybe we should
  Ted> start with simple tiling and add irregular
  Ted> grids later.

Agreed.

Let's start simple and see how things develop.

The API that you suggested is a fine starting point.

  MB> So, I am proposing experimentation with the following
  MB> hierarchy:

  MB> - Bare-Frames (no mini-buf, no menu, ...)
  MB>    - Related Windows
  MB>        - Panels (Collection of Tiles)
  MB>            - Tiles (Optionally Live and Active)

  Ted> Yes.  We're at bare frames now, slowly moving towards panels and tiles.
  Ted> I think a panel should be a frame.  I'm not sure what related windows
  Ted> are.

By related windows I meant things similar to the
(calc-keypad) where one window is the keypad
(panel of tiles) and the related window is the RPN
stack.

We can see how things evolve and revisit.

Thanks for considering my requests.

...Mohsen

Re: just-the-text Emacs frame

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Thu, 02 Jun 2011 08:15:31 -0500
> 
> >> Can this pop up a frame without a title bar, much like what tooltip
> >> does?
> 
> EZ> Not without some help from the display engine on the C level, AFAICT.
> EZ> Tooltips are special kind of frame treated specially by redisplay.
> 
> I always thought frame decorations came from the window manager; is
> there a way to tell it "I draw my own title bar"?

I'm not an expert on this, so I don't know.  However, if you grep the
Emacs sources for "tip_frame", you will see how many places give
special treatment to tooltip frames.

Re: just-the-text Emacs frame

[Leo]

On 2011-06-02 21:15 +0800, Ted Zlatanov wrote:
> I wouldn't go as far as a tooltip, though.  I think it's important that
> the emacs-panel popup frames be like any other Emacs frame, simply
> displaying a buffer.  That way we can use all the normal buffer-level
> facilities when we display things inside emacs-panel popups, like text
> properties and image overlays and UI elements.

tooltip uses buffer to show the contents so it is very flexible. We only
need to change it to receive mouse-click event and then it is turned
into a capable notification system.

Leo

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Fri, 03 Jun 2011 10:40:50 +0800 Leo <sdl.web@gmail.com> wrote: 

L> On 2011-06-02 21:15 +0800, Ted Zlatanov wrote:
>> I wouldn't go as far as a tooltip, though.  I think it's important that
>> the emacs-panel popup frames be like any other Emacs frame, simply
>> displaying a buffer.  That way we can use all the normal buffer-level
>> facilities when we display things inside emacs-panel popups, like text
>> properties and image overlays and UI elements.

L> tooltip uses buffer to show the contents so it is very flexible. We only
L> need to change it to receive mouse-click event and then it is turned
L> into a capable notification system.

Can you show an example of displaying arbitrary text with font
properties and images in a tooltip immediately, please?  I don't see it
in the manual.

Thanks
Ted

Re: just-the-text Emacs frame

[Leo]

On 2011-06-03 19:36 +0800, Ted Zlatanov wrote:
[snipped 13 lines]
> Can you show an example of displaying arbitrary text with font
> properties and images in a tooltip immediately, please?  I don't see it
> in the manual.
>
> Thanks
> Ted

Add them as properties to TEXT to tooltip-show. Note the text is
inserted into " *tip*" buffer.

Leo

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Fri, 03 Jun 2011 19:55:34 +0800 Leo <sdl.web@gmail.com> wrote: 

L> On 2011-06-03 19:36 +0800, Ted Zlatanov wrote:
L> [snipped 13 lines]
>> Can you show an example of displaying arbitrary text with font
>> properties and images in a tooltip immediately, please?  I don't see it
>> in the manual.
>> 
>> Thanks
>> Ted

L> Add them as properties to TEXT to tooltip-show. Note the text is
L> inserted into " *tip*" buffer.

(btw, I realized "immediately" could be seen as a rude demand to provide
the info immediately.  I meant the code should bring the tooltip up
immediately :)

There can only be one tooltip at a time.  That's not so good.  It could
be used for quick notifications but not for persistent desktop elements,
since it will conflict with any regular tooltips.

Ted

Re: just-the-text Emacs frame

[Leo]

On 2011-06-03 23:15 +0800, Ted Zlatanov wrote:
> There can only be one tooltip at a time.  That's not so good.  It could
> be used for quick notifications but not for persistent desktop elements,
> since it will conflict with any regular tooltips.

tooltip-hide is called in pre-command-hook and x-show-tip. The facility
provided cannot not be readily used for notifications but it does not
require much change.

Leo

Re: just-the-text Emacs frame

[Eli Zaretskii]

> From: Leo <sdl.web@gmail.com>
> Date: Sat, 04 Jun 2011 11:51:40 +0800
> 
> On 2011-06-03 23:15 +0800, Ted Zlatanov wrote:
> > There can only be one tooltip at a time.  That's not so good.  It could
> > be used for quick notifications but not for persistent desktop elements,
> > since it will conflict with any regular tooltips.
> 
> tooltip-hide is called in pre-command-hook and x-show-tip.

But you can increase tooltip-hide-delay to a very large value, right?

Re: just-the-text Emacs frame

[Julien Danjou]

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

On Thu, Jun 02 2011, Ted Zlatanov wrote:

> I always thought frame decorations came from the window manager; is
> there a way to tell it "I draw my own title bar"?  I think Google Chrome
> does that.  If there's a frame property we can add at the C level to
> hint this, it would make emacs-panel popups better and probably be nice
> for Emacs in general.

What you may want ultimately, is to be able to set various window types¹
on an Emacs frame.

Setting an Emacs frame the type DOCK will allow it to be attracted to
one of the frame edge, directly by the window manager. Setting it the
STRUT parameter will allow to reserve some place in the screen.

I've started to work on that 6 months ago, my work is available in a
branch². I can't recall if it's working totally, but I remember it was
at least in a good way. However it might be a start.


¹  http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2551529

²  http://git.naquadah.org/?p=~jd/emacs.git;a=shortlog;h=refs/heads/jd/strut-dock

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Fri, 03 Jun 2011 11:24:48 +0200 Julien Danjou <julien@danjou.info> wrote: 

JD> On Thu, Jun 02 2011, Ted Zlatanov wrote:
>> I always thought frame decorations came from the window manager; is
>> there a way to tell it "I draw my own title bar"?  I think Google Chrome
>> does that.  If there's a frame property we can add at the C level to
>> hint this, it would make emacs-panel popups better and probably be nice
>> for Emacs in general.

JD> What you may want ultimately, is to be able to set various window types¹
JD> on an Emacs frame.

JD> Setting an Emacs frame the type DOCK will allow it to be attracted to
JD> one of the frame edge, directly by the window manager. Setting it the
JD> STRUT parameter will allow to reserve some place in the screen.

That would be useful, although I still want to directly set the GTK
decorated and deletable properties.  All of these abilities will combine
to give emacs-panel.el the flexibility it needs to provide a desktop
environment.

JD> I've started to work on that 6 months ago, my work is available in a
JD> branch². I can't recall if it's working totally, but I remember it was
JD> at least in a good way. However it might be a start.

JD> ¹  http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2551529

JD> ²  http://git.naquadah.org/?p=~jd/emacs.git;a=shortlog;h=refs/heads/jd/strut-dock

I would really like it if someone who works with the Emacs GTK code
could look at your work.  It would be really useful to me and seems like
a low-risk feature.

Ted

Re: just-the-text Emacs frame

[Julien Danjou]

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

On Fri, Jun 03 2011, Ted Zlatanov wrote:

> That would be useful, although I still want to directly set the GTK
> decorated and deletable properties.  All of these abilities will combine
> to give emacs-panel.el the flexibility it needs to provide a desktop
> environment.

Actually, you may need that. Setting a correct window type is enough to
not have the window manager decorating the window.

I clearly had the same (kind of) idea as you have about creating an
Emacs based DE. To me what was missing was the possibility to make a
panel, this is why I've started my strut-dock branch. :)

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Fri, 03 Jun 2011 15:16:22 +0200 Julien Danjou <julien@danjou.info> wrote: 

JD> I clearly had the same (kind of) idea as you have about creating an
JD> Emacs based DE. To me what was missing was the possibility to make a
JD> panel, this is why I've started my strut-dock branch. :)

emacs-panel.el will be a package in the GNU ELPA (I hope), so if you can
commit there you can work on it too.  I'd like to avoid depending on any
particular features like your WM strut+dock support, the GTK
decorated+deletable properties I asked for, etc.  That way it can be
used in older Emacs versions and in XEmacs.  So if you can merge your
strut+dock work into the Emacs trunk that's great, but it's not critical.

Ted

Re: just-the-text Emacs frame

[Julien Danjou]

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

On Fri, Jun 03 2011, Ted Zlatanov wrote:

> emacs-panel.el will be a package in the GNU ELPA (I hope), so if you can
> commit there you can work on it too.  I'd like to avoid depending on any
> particular features like your WM strut+dock support, the GTK
> decorated+deletable properties I asked for, etc.  That way it can be
> used in older Emacs versions and in XEmacs.  So if you can merge your
> strut+dock work into the Emacs trunk that's great, but it's not critical.

I understand. Sure it's not critical, but it'll be a lot better if you
can use it! :) I'll try to rework and merge it someday. Maybe your
package will motivate me. :-)

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: just-the-text Emacs frame

[Jan Djärv]

Ted Zlatanov skrev 2011-06-03 17.11:
> On Fri, 03 Jun 2011 15:16:22 +0200 Julien Danjou<julien@danjou.info>  wrote:
>
> JD>  I clearly had the same (kind of) idea as you have about creating an
> JD>  Emacs based DE. To me what was missing was the possibility to make a
> JD>  panel, this is why I've started my strut-dock branch. :)
>
> emacs-panel.el will be a package in the GNU ELPA (I hope), so if you can
> commit there you can work on it too.  I'd like to avoid depending on any
> particular features like your WM strut+dock support, the GTK
> decorated+deletable properties I asked for, etc.  That way it can be
> used in older Emacs versions and in XEmacs.  So if you can merge your
> strut+dock work into the Emacs trunk that's great, but it's not critical.

I'm not so positive to the strut+windw type modifications for three reasons:

1) It can all be done in Lisp in a current Emacs without code modifications 
(well you have to unmap and remap for window type to take effect, so that is a 
bit ugly).
2) Strut is intended for pagers, panel and such, Emacs is not that kind of 
application.
3) Window types interract with override redirect and just setting the window 
type might not do the expected thing for all window managers.

Window type might have uses, but then override redirect should be handeled 
correctly also.  I don't think strut is suitable in Emacs.

	Jan D.

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Fri, 03 Jun 2011 18:30:42 +0200 Jan Djärv <jan.h.d@swipnet.se> wrote: 

JD> Ted Zlatanov skrev 2011-06-03 17.11:
>> emacs-panel.el will be a package in the GNU ELPA (I hope), so if you can
>> commit there you can work on it too.  I'd like to avoid depending on any
>> particular features like your WM strut+dock support, the GTK
>> decorated+deletable properties I asked for, etc.  That way it can be
>> used in older Emacs versions and in XEmacs.  So if you can merge your
>> strut+dock work into the Emacs trunk that's great, but it's not critical.

JD> I'm not so positive to the strut+windw type modifications for three reasons:

JD> 1) It can all be done in Lisp in a current Emacs without code
JD> modifications (well you have to unmap and remap for window type to
JD> take effect, so that is a bit ugly).

If so, that's good news; it doesn't matter if it's ugly if it can be
abstracted inside emacs-panel.el.

JD> 2) Strut is intended for pagers, panel and such, Emacs is not that
JD> kind of application.

I want emacs-panel.el to do the job of gnome-panel.  So I'd like Emacs
to look like a panel.  Specifically, it would be ideal if the WM could
automatically place a special Emacs frame on a screen edge and keep it
on top of others (which IIUC is a strut).  I also need the frame to have
no decorations but that's another thread :)

JD> 3) Window types interract with override redirect and just setting the
JD> window type might not do the expected thing for all window managers.

JD> Window type might have uses, but then override redirect should be
JD> handeled correctly also.  I don't think strut is suitable in Emacs.

If you think it's not going to work, OK.  But it would be nice.

Ted

Re: just-the-text Emacs frame

[Jan Djärv]

Ted Zlatanov skrev 2011-06-03 19.37:

>
> I want emacs-panel.el to do the job of gnome-panel.  So I'd like Emacs
> to look like a panel.  Specifically, it would be ideal if the WM could
> automatically place a special Emacs frame on a screen edge and keep it
> on top of others (which IIUC is a strut).  I also need the frame to have
> no decorations but that's another thread :)

This might not behave as you wish.  Some window managers (metacity at least) 
apply struts to all windows made by an application if one window has struts 
set.  For Emacs that would mean that if you set struts on one frame, it 
applies to all frames.

	Jan D.

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Fri, 03 Jun 2011 20:06:02 +0200 Jan Djärv <jan.h.d@swipnet.se> wrote: 

JD> Ted Zlatanov skrev 2011-06-03 19.37:

>> I want emacs-panel.el to do the job of gnome-panel.  So I'd like Emacs
>> to look like a panel.  Specifically, it would be ideal if the WM could
>> automatically place a special Emacs frame on a screen edge and keep it
>> on top of others (which IIUC is a strut).  I also need the frame to have
>> no decorations but that's another thread :)

JD> This might not behave as you wish.  Some window managers (metacity at
JD> least) apply struts to all windows made by an application if one
JD> window has struts set.  For Emacs that would mean that if you set
JD> struts on one frame, it applies to all frames.

It would be strange to run emacs-panel.el in a normal session, it's
intended to be run by itself (its 1-second timer makes it unpleasant
interactively).  So it may actually work OK if the strut treatment is
all-or-none.

Ted

Re: just-the-text Emacs frame

[Julien Danjou]

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

On Fri, Jun 03 2011, Jan Djärv wrote:

> This might not behave as you wish.  Some window managers (metacity at least)
> apply struts to all windows made by an application if one window has struts
> set.  For Emacs that would mean that if you set struts on one frame, it
> applies to all frames.

I don't believe you. That sounds like an extra amount of code to write
that would break EWMH explicitely. Quickly reading Metacity source code
makes me believe that you're wrong too.

(Now, I don't have time to find/write an app to check that, so, one of
us is wrong! :-)

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: just-the-text Emacs frame

[Jan Djärv]

Julien Danjou skrev 2011-06-06 10.38:
> On Fri, Jun 03 2011, Jan Djärv wrote:
>
>> This might not behave as you wish.  Some window managers (metacity at least)
>> apply struts to all windows made by an application if one window has struts
>> set.  For Emacs that would mean that if you set struts on one frame, it
>> applies to all frames.
>
> I don't believe you. That sounds like an extra amount of code to write
> that would break EWMH explicitely. Quickly reading Metacity source code
> makes me believe that you're wrong too.
>
> (Now, I don't have time to find/write an app to check that, so, one of
> us is wrong! :-)
>

I tried this with Emacs and it does behave the way I described.  If it is a 
metacity bug or not, I don't know.

	Jan D.

Re: just-the-text Emacs frame

[Jan Djärv]

On further testing, what I saw was just the application of struts which was 
confusing.  Ignore my comment about this.

	Jan D.


Jan Djärv skrev 2011-06-06 11.23:
>
>
> Julien Danjou skrev 2011-06-06 10.38:
>> On Fri, Jun 03 2011, Jan Djärv wrote:
>>
>>> This might not behave as you wish. Some window managers (metacity at least)
>>> apply struts to all windows made by an application if one window has struts
>>> set. For Emacs that would mean that if you set struts on one frame, it
>>> applies to all frames.
>>
>> I don't believe you. That sounds like an extra amount of code to write
>> that would break EWMH explicitely. Quickly reading Metacity source code
>> makes me believe that you're wrong too.
>>
>> (Now, I don't have time to find/write an app to check that, so, one of
>> us is wrong! :-)
>>
>
> I tried this with Emacs and it does behave the way I described. If it is a
> metacity bug or not, I don't know.
>
> Jan D.

Re: just-the-text Emacs frame

[Julien Danjou]

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

On Mon, Jun 06 2011, Jan Djärv wrote:

> Julien Danjou skrev 2011-06-06 10.38:
>> On Fri, Jun 03 2011, Jan Djärv wrote:
>>
>>> This might not behave as you wish.  Some window managers (metacity at least)
>>> apply struts to all windows made by an application if one window has struts
>>> set.  For Emacs that would mean that if you set struts on one frame, it
>>> applies to all frames.
>>
>> I don't believe you. That sounds like an extra amount of code to write
>> that would break EWMH explicitely. Quickly reading Metacity source code
>> makes me believe that you're wrong too.
>>
>> (Now, I don't have time to find/write an app to check that, so, one of
>> us is wrong! :-)
>>
>
> I tried this with Emacs and it does behave the way I described.  If it is a
> metacity bug or not, I don't know.

So we may not be talking about the same thing. But I just tried (thanks
for the tip, I know see that my old branch is useless) using your hint:

#+begin_src: emacs-lisp
(defun make-special-frame ()
  (let* ((width 200)
         (height 500)
         (ff (make-frame `((visibility . nil)
                           (width . 20)))))
    (x-change-window-property "_NET_WM_STRUT_PARTIAL" `(,width 0 0 0 0 ,height 0 0 0 0 0 0) ff
                              "CARDINAL" 32 t)
    (x-change-window-property "_NET_WM_WINDOW_TYPE" '("_NET_WM_WINDOW_TYPE_DOCK") ff
                              "ATOM" 32 t)
    (make-frame-visible ff)))
#+end_src

This, under awesome and Metacity, creates a new frame and reserves 50
pixels on the left of the screen for the frame. It does not affect any
other Emacs frame.

Both awesome and metacity drops the window decoration because they
recognise the window as a dock, and reserve the space. I think this is
exactly what Ted wants, except portability.

I just miss a way to set the Emacs frame width and height in pixel.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Mon, 06 Jun 2011 12:00:27 +0200 Julien Danjou <julien@danjou.info> wrote: 

#+begin_src: emacs-lisp
(defun make-special-frame ()
  (let* ((width 200)
	 (height 500)
	 (ff (make-frame `((visibility . nil)
			   (width . 20)))))
    (x-change-window-property "_NET_WM_STRUT_PARTIAL" `(,width 0 0 0 0 ,height 0 0 0 0 0 0) ff
			      "CARDINAL" 32 t)
    (x-change-window-property "_NET_WM_WINDOW_TYPE" '("_NET_WM_WINDOW_TYPE_DOCK") ff
			      "ATOM" 32 t)
    (make-frame-visible ff)))
#+end_src

JD> This, under awesome and Metacity, creates a new frame and reserves 50
JD> pixels on the left of the screen for the frame. It does not affect any
JD> other Emacs frame.

JD> Both awesome and metacity drops the window decoration because they
JD> recognise the window as a dock, and reserve the space. I think this is
JD> exactly what Ted wants, except portability.

Under XMonad, that creates a strut panel but the panel won't take any
keyboard input, which is a problem.  When I try to close it from the WM,
the WM targets another frame instead (the strut panel is not a normal
window, as expected).  It can be closed from the menus, but if I turn
off the menus as I intend, there will be no way to easily close that
frame.

I guess I can install a right-click handler, but I wonder if it's not
better to let emacs-panel manage all the popup frames it creates,
arranging them along the screen edges.  The lack of keyboard input
handling concerns me.  Does keyboard input work in other WMs?  I realize
this is way beyond the intended use of Emacs, so don't take it as a
complaint, more of an investigation :)

Thanks
Ted

Re: just-the-text Emacs frame

[Julien Danjou]

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

On Mon, Jun 06 2011, Ted Zlatanov wrote:

> Under XMonad, that creates a strut panel but the panel won't take any
> keyboard input, which is a problem.

I think this is a XMonad bug. I'd suggest talking to them to figure out
why they are refusing to give the focus to such a window.

> When I try to close it from the WM,
> the WM targets another frame instead (the strut panel is not a normal
> window, as expected).  It can be closed from the menus, but if I turn
> off the menus as I intend, there will be no way to easily close that
> frame.

Yes, it makes sense. XMonad refuses to give it the focus both internally
and in X so it can't logically receive any event.

> I guess I can install a right-click handler, but I wonder if it's not
> better to let emacs-panel manage all the popup frames it creates,
> arranging them along the screen edges.  The lack of keyboard input
> handling concerns me.  Does keyboard input work in other WMs?  I realize
> this is way beyond the intended use of Emacs, so don't take it as a
> complaint, more of an investigation :)

Yeah, it works fine under others WM I tested. Really, I think it's a
bug. :)

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Tue, 07 Jun 2011 10:25:54 +0200 Julien Danjou <julien@danjou.info> wrote: 

JD> On Mon, Jun 06 2011, Ted Zlatanov wrote:
>> Under XMonad, that creates a strut panel but the panel won't take any
>> keyboard input, which is a problem.

JD> I think this is a XMonad bug. I'd suggest talking to them to figure out
JD> why they are refusing to give the focus to such a window.

I did.  They claim it's necessary because other panels have a heart
attack when they get the keyboard input focus.  So the solution is to
configure it at the user level, since they can't match dock rules to
Emacs frames in general (I've asked for more help but it doesn't seem to
be a priority to the XMonad developers, and I don't know Haskell enough
to do this myself).

So unless I get further help, I'll just document that XMonad is not
perfect for Emacs docked strut frames and I'll provide mouse bindings to
most of the things in such frames, including a binding to pop their
buffer up in a normal frame.

Ted

Re: just-the-text Emacs frame

[T.V. Raman]

I+haven%27t+seen+stumpwm+mentioned+in+this+thread+%2D%2D%2D+I+too%

On 6/10/11, Ted Zlatanov <tzz@lifelogs.com> wrote:
> On Tue, 07 Jun 2011 10:25:54 +0200 Julien Danjou <julien@danjou.info> wrote:
>
> JD> On Mon, Jun 06 2011, Ted Zlatanov wrote:
>>> Under XMonad, that creates a strut panel but the panel won't take any
>>> keyboard input, which is a problem.
>
> JD> I think this is a XMonad bug. I'd suggest talking to them to figure out
> JD> why they are refusing to give the focus to such a window.
>
> I did.  They claim it's necessary because other panels have a heart
> attack when they get the keyboard input focus.  So the solution is to
> configure it at the user level, since they can't match dock rules to
> Emacs frames in general (I've asked for more help but it doesn't seem to
> be a priority to the XMonad developers, and I don't know Haskell enough
> to do this myself).
>
> So unless I get further help, I'll just document that XMonad is not
> perfect for Emacs docked strut frames and I'll provide mouse bindings to
> most of the things in such frames, including a binding to pop their
> buffer up in a normal frame.
>
> Ted
>
>
>

Re: just-the-text Emacs frame

[chad]

On Jun 10, 2011, at 9:28 AM, Ted Zlatanov wrote:

> I did.  They claim it's necessary because other panels have a heart
> attack when they get the keyboard input focus.  So the solution is to
> configure it at the user level, since they can't match dock rules to
> Emacs frames in general (I've asked for more help but it doesn't seem to
> be a priority to the XMonad developers, and I don't know Haskell enough
> to do this myself).
> 
> So unless I get further help, I'll just document that XMonad is not
> perfect for Emacs docked strut frames and I'll provide mouse bindings to
> most of the things in such frames, including a binding to pop their
> buffer up in a normal frame.

It ought to be possible to cover this in the configurations; for years, my 
window managers thought that I ran programs named (from X's pov) 
RightEmacs, LeftEmacs, and MiniBuffer.

I don't currently have a good way to test XMonad, and won't for a couple 
weeks at least.  If it helps, you could try to figure out what configuration 
awesome and metacity have that XMonad does not, probably with some 
judicious use of xprop.

Hope that helps,
*Chad

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Fri, 10 Jun 2011 11:57:37 -0700 chad <yandros@MIT.EDU> wrote: 

c> On Jun 10, 2011, at 9:28 AM, Ted Zlatanov wrote:

>> I did.  They claim it's necessary because other panels have a heart
>> attack when they get the keyboard input focus.  So the solution is to
>> configure it at the user level, since they can't match dock rules to
>> Emacs frames in general (I've asked for more help but it doesn't seem to
>> be a priority to the XMonad developers, and I don't know Haskell enough
>> to do this myself).
>> 
>> So unless I get further help, I'll just document that XMonad is not
>> perfect for Emacs docked strut frames and I'll provide mouse bindings to
>> most of the things in such frames, including a binding to pop their
>> buffer up in a normal frame.

c> It ought to be possible to cover this in the configurations; for years, my 
c> window managers thought that I ran programs named (from X's pov) 
c> RightEmacs, LeftEmacs, and MiniBuffer.

I understand, but there is no way to match "Emacs frames that want to be
a panel" unambiguously without making the window title static, and then
you have to put that title in your XMonad user configuration, which is
what I'm trying to avoid.  I need a way to tell XMonad is running, then
I can require static titles for dock panels under that WM alone.  I got
some hints from
http://stackoverflow.com/questions/758648/find-the-name-of-the-x-window-manager
and put the following in emacs-panel.el:

#+begin_src lisp
(require 'bindat)

(defmacro emacs-panel-x-property (prop window &optional type vec)
  `(x-window-property ,prop nil ,(or type "AnyPropertyType") ,window nil ,vec))

(defmacro emacs-panel-x-property-nullsepstringarray (prop window &optional type)
  `(split-string (emacs-panel-x-property ,prop ,window ,type) "\0" t))

(defmacro emacs-panel-x-property-u32r (prop window &optional type)
  `(let ((spec '((:v u32r)))
         (bin (emacs-panel-x-property ,prop ,window ,type)))
     (cdr-safe (assq :v (bindat-unpack spec bin)))))

(defun emacs-panel-wm-hints ()
  ;; ask the root window what window to query for the WM name
  (let* ((nqid (emacs-panel-x-property-u32r "_NET_SUPPORTING_WM_CHECK" 0))
         (name (emacs-panel-x-property "_NET_WM_NAME" nqid)))
    `((name ,name)
      (desktop-names
       ,@(emacs-panel-x-property-nullsepstringarray "_NET_DESKTOP_NAMES" 0))
      (active-window
       ,(emacs-panel-x-property-u32r "_NET_ACTIVE_WINDOW" 0))
      (desktop-count
       ,(emacs-panel-x-property-u32r "_NET_NUMBER_OF_DESKTOPS" 0))
      (current-desktop
       ,(emacs-panel-x-property-u32r "_NET_CURRENT_DESKTOP" 0)))))

#+end_src

(emacs-panel-wm-hints)
=> ((name "xmonad") (desktop-names "ext" "db" "web" "emacs" "gnus") (active-window 48234572) (desktop-count 5) (current-desktop 4))

so I will be able to tell the user "hey, XMonad doesn't like docked
struts, but here's what you can do..."

c> I don't currently have a good way to test XMonad, and won't for a couple 
c> weeks at least.  If it helps, you could try to figure out what configuration 
c> awesome and metacity have that XMonad does not, probably with some 
c> judicious use of xprop.

Regardless of the X properties of a docked strut Emacs frame (outside of
the WM hints to make it docked and a strut, obviously), awesome and
metacity give it the keyboard input focus and XMonad doesn't, by design.

I didn't get the impression the XMonad developers were interested in
making an exception for Emacs, since to them it seems sufficient that
the user can configure the exception himself.  And perhaps it is.

Ted

Re: just-the-text Emacs frame

[Philipp Haselwarter]

On 2011-06-10 16:28 UT, Ted Zlatanov <tzz@lifelogs.com> wrote:

TZ> On Tue, 07 Jun 2011 10:25:54 +0200 Julien Danjou <julien@danjou.info> wrote:

JD> On Mon, Jun 06 2011, Ted Zlatanov wrote:
>>> Under XMonad, that creates a strut panel but the panel won't take
>>> any keyboard input, which is a problem.

JD> I think this is a XMonad bug.I'd suggest talking to them to figure
JD> out why they are refusing to give the focus to such a window.

TZ> I did.They claim it's necessary because other panels have a heart
TZ> attack when they get the keyboard input focus.So the solution is to
TZ> configure it at the user level, since they can't match dock rules to
TZ> Emacs frames in general (I've asked for more help but it doesn't
TZ> seem to be a priority to the XMonad developers, and I don't know
TZ> Haskell enough to do this myself).

TZ> So unless I get further help, I'll just document that XMonad is not
TZ> perfect for Emacs docked strut frames and I'll provide mouse
TZ> bindings to most of the things in such frames, including a binding
TZ> to pop their buffer up in a normal frame.

TZ> Ted

I assume you use manageDocks on your manageHook?
manageDocks simply does

#+begin_src haskell
manageDocks :: ManageHook
manageDocks = checkDock --> doIgnore
#+end_src

If you want more fine grained control, just ignore the docks you really
just want out of your way and set windows with  _NET_WM_WINDOW_TYPE_DOCK
to be floating. That way, they can still get focus and input.
And don't forget to put avoidStruts on your layout.

Could give you something like this:

#+begin_src haskell
myManageHook = composeAll . concat $
    [ [ className =? i --> doIgnore | i <- myCIgnores ]
    , [ className =? c --> doFloat  | c <- myCFloats  ]
    , [ title     =? t --> doFloat  | t <- myTFloats  ]
    , [ resource  =? r --> doFloat  | r <- myRFloats  ]
    , [ resource  =? i --> doIgnore | i <- myRIgnores ]
    , [ isFullscreen   --> doFullFloat ]
    , [ isDialog       --> doFloat     ]
    , [ checkDock      --> doFloat     ]
    , [ (className =? x <||> title =? x <||> resource =? x) --> doF (W.shift (myWorkspaces !! 1)) | x <- my1Shifts ]
    , [ (className =? x <||> title =? x <||> resource =? x) --> doShift (myWorkspaces !! 2) | x <- my2Shifts       ]
    ]
    where
    myCFloats  = [ "MPlayer", "Vlc", "Gimp", "Volume-control.py" ]
    myTFloats  = []
    myRFloats  = []
    myCIgnores = [ "dzen", "Avant-window-navigator" ]
    myRIgnores = [ "kdesktop", "desktop_window" ]
    my1Shifts  = [ "Nightly" ]
    my2Shifts  = []
#+end_src

Simply adjust myCIgnores or myRIgnores according to what docks you use.

-- 
Philipp Haselwarter

Re: just-the-text Emacs frame

[Ted Zlatanov]

On Sat, 11 Jun 2011 10:04:59 +0200 Philipp Haselwarter <philipp.haselwarter@gmx.de> wrote: 

PH> I assume you use manageDocks on your manageHook?
PH> manageDocks simply does
#+begin_src haskell
manageDocks :: ManageHook
manageDocks = checkDock --> doIgnore
#+end_src

PH> If you want more fine grained control, just ignore the docks you really
PH> just want out of your way and set windows with  _NET_WM_WINDOW_TYPE_DOCK
PH> to be floating. That way, they can still get focus and input.
PH> And don't forget to put avoidStruts on your layout.

PH> Could give you something like this:
#+begin_src haskell
myManageHook = composeAll . concat $
    [ [ className =? i --> doIgnore | i <- myCIgnores ]
    , [ className =? c --> doFloat  | c <- myCFloats  ]
    , [ title     =? t --> doFloat  | t <- myTFloats  ]
    , [ resource  =? r --> doFloat  | r <- myRFloats  ]
    , [ resource  =? i --> doIgnore | i <- myRIgnores ]
    , [ isFullscreen   --> doFullFloat ]
    , [ isDialog       --> doFloat     ]
    , [ checkDock      --> doFloat     ]
    , [ (className =? x <||> title =? x <||> resource =? x) --> doF (W.shift (myWorkspaces !! 1)) | x <- my1Shifts ]
    , [ (className =? x <||> title =? x <||> resource =? x) --> doShift (myWorkspaces !! 2) | x <- my2Shifts       ]
    ]
    where
    myCFloats  = [ "MPlayer", "Vlc", "Gimp", "Volume-control.py" ]
    myTFloats  = []
    myRFloats  = []
    myCIgnores = [ "dzen", "Avant-window-navigator" ]
    myRIgnores = [ "kdesktop", "desktop_window" ]
    my1Shifts  = [ "Nightly" ]
    my2Shifts  = []
#+end_src

PH> Simply adjust myCIgnores or myRIgnores according to what docks you use.

That sounds good.  I'll put something like that in the emacs-panel
recommendation and docs for when it detects you're running XMonad.

Thanks
Ted

Re: just-the-text Emacs frame

[Julien Danjou]

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

On Fri, Jun 03 2011, Jan Djärv wrote:

> 1) It can all be done in Lisp in a current Emacs without code modifications
> (well you have to unmap and remap for window type to take effect, so that is
> a bit ugly).

Do you mean the X primitive are accessible from Lisp? I never saw that
in Emacs, so pointer appreciated!

> 2) Strut is intended for pagers, panel and such, Emacs is not that kind of
> application.

But it could be. I don't see why it could not at least.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: just-the-text Emacs frame

[Jan Djärv]

Julien Danjou skrev 2011-06-06 10.32:
> On Fri, Jun 03 2011, Jan Djärv wrote:
>
>> 1) It can all be done in Lisp in a current Emacs without code modifications
>> (well you have to unmap and remap for window type to take effect, so that is
>> a bit ugly).
>
> Do you mean the X primitive are accessible from Lisp? I never saw that
> in Emacs, so pointer appreciated!
>

See the other messages in this thread about MotifWMHints.

	Jan D.