* Re: just-the-text Emacs frame @ 2011-06-10 17:38 T. V. Raman 0 siblings, 0 replies; 45+ messages in thread From: T. V. Raman @ 2011-06-10 17:38 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Emacs as a desktop environment @ 2011-05-25 1:05 Ted Zlatanov 2011-05-26 0:58 ` Eric M. Ludlam 0 siblings, 1 reply; 45+ messages in thread From: Ted Zlatanov @ 2011-05-25 1:05 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Emacs as a desktop environment 2011-05-25 1:05 Emacs as a desktop environment Ted Zlatanov @ 2011-05-26 0:58 ` Eric M. Ludlam 2011-05-26 15:21 ` Ted Zlatanov 0 siblings, 1 reply; 45+ messages in thread From: Eric M. Ludlam @ 2011-05-26 0:58 UTC (permalink / raw) To: Ted Zlatanov; +Cc: emacs-devel 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 > > > ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Emacs as a desktop environment 2011-05-26 0:58 ` Eric M. Ludlam @ 2011-05-26 15:21 ` Ted Zlatanov 2011-05-26 16:38 ` joakim 0 siblings, 1 reply; 45+ messages in thread From: Ted Zlatanov @ 2011-05-26 15:21 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Emacs as a desktop environment 2011-05-26 15:21 ` Ted Zlatanov @ 2011-05-26 16:38 ` joakim 2011-05-27 12:50 ` Ted Zlatanov 0 siblings, 1 reply; 45+ messages in thread From: joakim @ 2011-05-26 16:38 UTC (permalink / raw) To: Ted Zlatanov; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Emacs as a desktop environment 2011-05-26 16:38 ` joakim @ 2011-05-27 12:50 ` Ted Zlatanov 2011-05-28 8:10 ` joakim 0 siblings, 1 reply; 45+ messages in thread From: Ted Zlatanov @ 2011-05-27 12:50 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Emacs as a desktop environment 2011-05-27 12:50 ` Ted Zlatanov @ 2011-05-28 8:10 ` joakim 2011-05-28 17:49 ` just-the-text Emacs frame (was: Emacs as a desktop environment) Ted Zlatanov 0 siblings, 1 reply; 45+ messages in thread From: joakim @ 2011-05-28 8:10 UTC (permalink / raw) To: Ted Zlatanov; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* just-the-text Emacs frame (was: Emacs as a desktop environment) 2011-05-28 8:10 ` joakim @ 2011-05-28 17:49 ` Ted Zlatanov 2011-05-28 20:18 ` just-the-text Emacs frame Thierry Volpiatto 2011-06-01 18:01 ` Ted Zlatanov 0 siblings, 2 replies; 45+ messages in thread From: Ted Zlatanov @ 2011-05-28 17:49 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-05-28 17:49 ` just-the-text Emacs frame (was: Emacs as a desktop environment) Ted Zlatanov @ 2011-05-28 20:18 ` Thierry Volpiatto 2011-05-28 22:06 ` Ted Zlatanov 2011-05-29 10:12 ` joakim 2011-06-01 18:01 ` Ted Zlatanov 1 sibling, 2 replies; 45+ messages in thread From: Thierry Volpiatto @ 2011-05-28 20:18 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-05-28 20:18 ` just-the-text Emacs frame Thierry Volpiatto @ 2011-05-28 22:06 ` Ted Zlatanov 2011-05-29 10:12 ` joakim 1 sibling, 0 replies; 45+ messages in thread From: Ted Zlatanov @ 2011-05-28 22:06 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-05-28 20:18 ` just-the-text Emacs frame Thierry Volpiatto 2011-05-28 22:06 ` Ted Zlatanov @ 2011-05-29 10:12 ` joakim 1 sibling, 0 replies; 45+ messages in thread From: joakim @ 2011-05-29 10:12 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-05-28 17:49 ` just-the-text Emacs frame (was: Emacs as a desktop environment) Ted Zlatanov 2011-05-28 20:18 ` just-the-text Emacs frame Thierry Volpiatto @ 2011-06-01 18:01 ` Ted Zlatanov 2011-06-02 2:43 ` Leo 1 sibling, 1 reply; 45+ messages in thread From: Ted Zlatanov @ 2011-06-01 18:01 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-01 18:01 ` Ted Zlatanov @ 2011-06-02 2:43 ` Leo 2011-06-02 4:05 ` Eli Zaretskii 0 siblings, 1 reply; 45+ messages in thread From: Leo @ 2011-06-02 2:43 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-02 2:43 ` Leo @ 2011-06-02 4:05 ` Eli Zaretskii 2011-06-02 13:15 ` Ted Zlatanov 0 siblings, 1 reply; 45+ messages in thread From: Eli Zaretskii @ 2011-06-02 4:05 UTC (permalink / raw) To: Leo; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-02 4:05 ` Eli Zaretskii @ 2011-06-02 13:15 ` Ted Zlatanov 2011-06-02 15:43 ` Mohsen BANAN ` (3 more replies) 0 siblings, 4 replies; 45+ messages in thread From: Ted Zlatanov @ 2011-06-02 13:15 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-02 13:15 ` Ted Zlatanov @ 2011-06-02 15:43 ` Mohsen BANAN 2011-06-02 17:41 ` Ted Zlatanov 2011-06-02 18:00 ` Eli Zaretskii ` (2 subsequent siblings) 3 siblings, 1 reply; 45+ messages in thread From: Mohsen BANAN @ 2011-06-02 15:43 UTC (permalink / raw) To: emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-02 15:43 ` Mohsen BANAN @ 2011-06-02 17:41 ` Ted Zlatanov 2011-06-02 20:19 ` Mohsen BANAN 0 siblings, 1 reply; 45+ messages in thread From: Ted Zlatanov @ 2011-06-02 17:41 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-02 17:41 ` Ted Zlatanov @ 2011-06-02 20:19 ` Mohsen BANAN 2011-06-02 21:06 ` Ted Zlatanov 2011-06-03 20:56 ` Ted Zlatanov 0 siblings, 2 replies; 45+ messages in thread From: Mohsen BANAN @ 2011-06-02 20:19 UTC (permalink / raw) To: emacs-devel, Ted Zlatanov >>>>> 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-02 20:19 ` Mohsen BANAN @ 2011-06-02 21:06 ` Ted Zlatanov 2011-06-03 15:09 ` Mohsen BANAN 2011-06-03 20:56 ` Ted Zlatanov 1 sibling, 1 reply; 45+ messages in thread From: Ted Zlatanov @ 2011-06-02 21:06 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-02 21:06 ` Ted Zlatanov @ 2011-06-03 15:09 ` Mohsen BANAN 0 siblings, 0 replies; 45+ messages in thread From: Mohsen BANAN @ 2011-06-03 15:09 UTC (permalink / raw) To: emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-02 20:19 ` Mohsen BANAN 2011-06-02 21:06 ` Ted Zlatanov @ 2011-06-03 20:56 ` Ted Zlatanov 2011-06-03 22:31 ` Mohsen BANAN 1 sibling, 1 reply; 45+ messages in thread From: Ted Zlatanov @ 2011-06-03 20:56 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-03 20:56 ` Ted Zlatanov @ 2011-06-03 22:31 ` Mohsen BANAN 0 siblings, 0 replies; 45+ messages in thread From: Mohsen BANAN @ 2011-06-03 22:31 UTC (permalink / raw) To: emacs-devel, Ted Zlatanov >>>>> 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-02 13:15 ` Ted Zlatanov 2011-06-02 15:43 ` Mohsen BANAN @ 2011-06-02 18:00 ` Eli Zaretskii 2011-06-03 2:40 ` Leo 2011-06-03 9:24 ` Julien Danjou 3 siblings, 0 replies; 45+ messages in thread From: Eli Zaretskii @ 2011-06-02 18:00 UTC (permalink / raw) To: emacs-devel > 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-02 13:15 ` Ted Zlatanov 2011-06-02 15:43 ` Mohsen BANAN 2011-06-02 18:00 ` Eli Zaretskii @ 2011-06-03 2:40 ` Leo 2011-06-03 11:36 ` Ted Zlatanov 2011-06-03 9:24 ` Julien Danjou 3 siblings, 1 reply; 45+ messages in thread From: Leo @ 2011-06-03 2:40 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-03 2:40 ` Leo @ 2011-06-03 11:36 ` Ted Zlatanov 2011-06-03 11:55 ` Leo 0 siblings, 1 reply; 45+ messages in thread From: Ted Zlatanov @ 2011-06-03 11:36 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-03 11:36 ` Ted Zlatanov @ 2011-06-03 11:55 ` Leo 2011-06-03 15:15 ` Ted Zlatanov 0 siblings, 1 reply; 45+ messages in thread From: Leo @ 2011-06-03 11:55 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-03 11:55 ` Leo @ 2011-06-03 15:15 ` Ted Zlatanov 2011-06-04 3:51 ` Leo 0 siblings, 1 reply; 45+ messages in thread From: Ted Zlatanov @ 2011-06-03 15:15 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-03 15:15 ` Ted Zlatanov @ 2011-06-04 3:51 ` Leo 2011-06-04 7:02 ` Eli Zaretskii 0 siblings, 1 reply; 45+ messages in thread From: Leo @ 2011-06-04 3:51 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-04 3:51 ` Leo @ 2011-06-04 7:02 ` Eli Zaretskii 0 siblings, 0 replies; 45+ messages in thread From: Eli Zaretskii @ 2011-06-04 7:02 UTC (permalink / raw) To: Leo; +Cc: emacs-devel > 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? ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-02 13:15 ` Ted Zlatanov ` (2 preceding siblings ...) 2011-06-03 2:40 ` Leo @ 2011-06-03 9:24 ` Julien Danjou 2011-06-03 11:40 ` Ted Zlatanov 3 siblings, 1 reply; 45+ messages in thread From: Julien Danjou @ 2011-06-03 9:24 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-03 9:24 ` Julien Danjou @ 2011-06-03 11:40 ` Ted Zlatanov 2011-06-03 13:16 ` Julien Danjou 0 siblings, 1 reply; 45+ messages in thread From: Ted Zlatanov @ 2011-06-03 11:40 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-03 11:40 ` Ted Zlatanov @ 2011-06-03 13:16 ` Julien Danjou 2011-06-03 15:11 ` Ted Zlatanov 0 siblings, 1 reply; 45+ messages in thread From: Julien Danjou @ 2011-06-03 13:16 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-03 13:16 ` Julien Danjou @ 2011-06-03 15:11 ` Ted Zlatanov 2011-06-03 15:27 ` Julien Danjou 2011-06-03 16:30 ` Jan Djärv 0 siblings, 2 replies; 45+ messages in thread From: Ted Zlatanov @ 2011-06-03 15:11 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-03 15:11 ` Ted Zlatanov @ 2011-06-03 15:27 ` Julien Danjou 2011-06-03 16:30 ` Jan Djärv 1 sibling, 0 replies; 45+ messages in thread From: Julien Danjou @ 2011-06-03 15:27 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-03 15:11 ` Ted Zlatanov 2011-06-03 15:27 ` Julien Danjou @ 2011-06-03 16:30 ` Jan Djärv 2011-06-03 17:37 ` Ted Zlatanov 2011-06-06 8:32 ` Julien Danjou 1 sibling, 2 replies; 45+ messages in thread From: Jan Djärv @ 2011-06-03 16:30 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-03 16:30 ` Jan Djärv @ 2011-06-03 17:37 ` Ted Zlatanov 2011-06-03 18:06 ` Jan Djärv 2011-06-06 8:32 ` Julien Danjou 1 sibling, 1 reply; 45+ messages in thread From: Ted Zlatanov @ 2011-06-03 17:37 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-03 17:37 ` Ted Zlatanov @ 2011-06-03 18:06 ` Jan Djärv 2011-06-03 19:08 ` Ted Zlatanov 2011-06-06 8:38 ` Julien Danjou 0 siblings, 2 replies; 45+ messages in thread From: Jan Djärv @ 2011-06-03 18:06 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-03 18:06 ` Jan Djärv @ 2011-06-03 19:08 ` Ted Zlatanov 2011-06-06 8:38 ` Julien Danjou 1 sibling, 0 replies; 45+ messages in thread From: Ted Zlatanov @ 2011-06-03 19:08 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-03 18:06 ` Jan Djärv 2011-06-03 19:08 ` Ted Zlatanov @ 2011-06-06 8:38 ` Julien Danjou 2011-06-06 9:23 ` Jan Djärv 1 sibling, 1 reply; 45+ messages in thread From: Julien Danjou @ 2011-06-06 8:38 UTC (permalink / raw) To: Jan Djärv; +Cc: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-06 8:38 ` Julien Danjou @ 2011-06-06 9:23 ` Jan Djärv 2011-06-06 9:34 ` Jan Djärv 2011-06-06 10:00 ` Julien Danjou 0 siblings, 2 replies; 45+ messages in thread From: Jan Djärv @ 2011-06-06 9:23 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-06 9:23 ` Jan Djärv @ 2011-06-06 9:34 ` Jan Djärv 2011-06-06 10:00 ` Julien Danjou 1 sibling, 0 replies; 45+ messages in thread From: Jan Djärv @ 2011-06-06 9:34 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-06 9:23 ` Jan Djärv 2011-06-06 9:34 ` Jan Djärv @ 2011-06-06 10:00 ` Julien Danjou 2011-06-06 20:52 ` Ted Zlatanov 1 sibling, 1 reply; 45+ messages in thread From: Julien Danjou @ 2011-06-06 10:00 UTC (permalink / raw) To: Jan Djärv; +Cc: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-06 10:00 ` Julien Danjou @ 2011-06-06 20:52 ` Ted Zlatanov 2011-06-07 8:25 ` Julien Danjou 0 siblings, 1 reply; 45+ messages in thread From: Ted Zlatanov @ 2011-06-06 20:52 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-06 20:52 ` Ted Zlatanov @ 2011-06-07 8:25 ` Julien Danjou 2011-06-10 16:28 ` Ted Zlatanov 0 siblings, 1 reply; 45+ messages in thread From: Julien Danjou @ 2011-06-07 8:25 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-07 8:25 ` Julien Danjou @ 2011-06-10 16:28 ` Ted Zlatanov 2011-06-10 17:35 ` T.V. Raman ` (2 more replies) 0 siblings, 3 replies; 45+ messages in thread From: Ted Zlatanov @ 2011-06-10 16:28 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-10 16:28 ` Ted Zlatanov @ 2011-06-10 17:35 ` T.V. Raman 2011-06-10 18:57 ` chad 2011-06-11 8:04 ` Philipp Haselwarter 2 siblings, 0 replies; 45+ messages in thread From: T.V. Raman @ 2011-06-10 17:35 UTC (permalink / raw) To: emacs-devel 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 > > > ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-10 16:28 ` Ted Zlatanov 2011-06-10 17:35 ` T.V. Raman @ 2011-06-10 18:57 ` chad 2011-06-10 20:53 ` Ted Zlatanov 2011-06-11 8:04 ` Philipp Haselwarter 2 siblings, 1 reply; 45+ messages in thread From: chad @ 2011-06-10 18:57 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-10 18:57 ` chad @ 2011-06-10 20:53 ` Ted Zlatanov 0 siblings, 0 replies; 45+ messages in thread From: Ted Zlatanov @ 2011-06-10 20:53 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-10 16:28 ` Ted Zlatanov 2011-06-10 17:35 ` T.V. Raman 2011-06-10 18:57 ` chad @ 2011-06-11 8:04 ` Philipp Haselwarter 2011-06-11 10:45 ` Ted Zlatanov 2 siblings, 1 reply; 45+ messages in thread From: Philipp Haselwarter @ 2011-06-11 8:04 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-11 8:04 ` Philipp Haselwarter @ 2011-06-11 10:45 ` Ted Zlatanov 0 siblings, 0 replies; 45+ messages in thread From: Ted Zlatanov @ 2011-06-11 10:45 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-03 16:30 ` Jan Djärv 2011-06-03 17:37 ` Ted Zlatanov @ 2011-06-06 8:32 ` Julien Danjou 2011-06-06 9:22 ` Jan Djärv 1 sibling, 1 reply; 45+ messages in thread From: Julien Danjou @ 2011-06-06 8:32 UTC (permalink / raw) To: Jan Djärv; +Cc: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: just-the-text Emacs frame 2011-06-06 8:32 ` Julien Danjou @ 2011-06-06 9:22 ` Jan Djärv 0 siblings, 0 replies; 45+ messages in thread From: Jan Djärv @ 2011-06-06 9:22 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
end of thread, other threads:[~2011-06-11 10:45 UTC | newest] Thread overview: 45+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-06-10 17:38 just-the-text Emacs frame T. V. Raman -- strict thread matches above, loose matches on Subject: below -- 2011-05-25 1:05 Emacs as a desktop environment Ted Zlatanov 2011-05-26 0:58 ` Eric M. Ludlam 2011-05-26 15:21 ` Ted Zlatanov 2011-05-26 16:38 ` joakim 2011-05-27 12:50 ` Ted Zlatanov 2011-05-28 8:10 ` joakim 2011-05-28 17:49 ` just-the-text Emacs frame (was: Emacs as a desktop environment) Ted Zlatanov 2011-05-28 20:18 ` just-the-text Emacs frame Thierry Volpiatto 2011-05-28 22:06 ` Ted Zlatanov 2011-05-29 10:12 ` joakim 2011-06-01 18:01 ` Ted Zlatanov 2011-06-02 2:43 ` Leo 2011-06-02 4:05 ` Eli Zaretskii 2011-06-02 13:15 ` Ted Zlatanov 2011-06-02 15:43 ` Mohsen BANAN 2011-06-02 17:41 ` Ted Zlatanov 2011-06-02 20:19 ` Mohsen BANAN 2011-06-02 21:06 ` Ted Zlatanov 2011-06-03 15:09 ` Mohsen BANAN 2011-06-03 20:56 ` Ted Zlatanov 2011-06-03 22:31 ` Mohsen BANAN 2011-06-02 18:00 ` Eli Zaretskii 2011-06-03 2:40 ` Leo 2011-06-03 11:36 ` Ted Zlatanov 2011-06-03 11:55 ` Leo 2011-06-03 15:15 ` Ted Zlatanov 2011-06-04 3:51 ` Leo 2011-06-04 7:02 ` Eli Zaretskii 2011-06-03 9:24 ` Julien Danjou 2011-06-03 11:40 ` Ted Zlatanov 2011-06-03 13:16 ` Julien Danjou 2011-06-03 15:11 ` Ted Zlatanov 2011-06-03 15:27 ` Julien Danjou 2011-06-03 16:30 ` Jan Djärv 2011-06-03 17:37 ` Ted Zlatanov 2011-06-03 18:06 ` Jan Djärv 2011-06-03 19:08 ` Ted Zlatanov 2011-06-06 8:38 ` Julien Danjou 2011-06-06 9:23 ` Jan Djärv 2011-06-06 9:34 ` Jan Djärv 2011-06-06 10:00 ` Julien Danjou 2011-06-06 20:52 ` Ted Zlatanov 2011-06-07 8:25 ` Julien Danjou 2011-06-10 16:28 ` Ted Zlatanov 2011-06-10 17:35 ` T.V. Raman 2011-06-10 18:57 ` chad 2011-06-10 20:53 ` Ted Zlatanov 2011-06-11 8:04 ` Philipp Haselwarter 2011-06-11 10:45 ` Ted Zlatanov 2011-06-06 8:32 ` Julien Danjou 2011-06-06 9:22 ` Jan Djärv
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).