view admin/notes/commits @ 109581:06384b3caebf

Add ability to put Gtk+ tool bar on the left/right/bottom or top. Default top. * lisp/menu-bar.el (menu-bar-showhide-tool-bar-menu-customize-enable-left) (menu-bar-showhide-tool-bar-menu-customize-disable) (menu-bar-showhide-tool-bar-menu-customize-enable-right) (menu-bar-showhide-tool-bar-menu-customize-enable-top) (menu-bar-showhide-tool-bar-menu-customize-enable-bottom): New functions (menu-bar-showhide-tool-bar-menu): If tool bar is moveable, make a menu for Options => toolbar that can move it. * src/frame.c (Qtool_bar_position): New variable. (make_frame): Set tool_bar_position to Qtop. (frame_parms): Add tool-bar-position. (x_report_frame_params): Store tool_bar_position. (x_set_fringe_width): Reset wm size hint after fringe changes. * src/frame.h (struct frame): Add tool_bar_position. (Qbottom): Declare. * src/gtkutil.c (FRAME_TOTAL_PIXEL_WIDTH): New macro. (xg_frame_set_char_size): Add FRAME_TOOLBAR_WIDTH to pixelwidth. (xg_height_or_width_changed): Use FRAME_TOTAL_PIXEL_WIDTH. (xg_create_frame_widgets): Create a hobox for placing widgets vertically. Use gtk_box_pack_start. (xg_height_or_width_changed): Renamed from xg_height_changed. (x_wm_set_size_hint): Add FRAME_TOOLBAR_WIDTH to base_width. (xg_update_frame_menubar, free_frame_menubar): Change to xg_height_or_width_changed. (xg_tool_bar_detach_callback): Update left/right/top/bottom tool bar size correctly. Remove hardcoded 4, instead use handlebox size - toolbar size. (xg_tool_bar_attach_callback): Update left/right/top/bottom tool bar size correctly. Use handlebox size + toolbar size as additional size. (xg_pack_tool_bar): POS is a new parameter. Set orientation of tool bar based on pos. Only make handlebox_widget if NULL. Check if tool bar goes to vbox or hbox depending on pos. (xg_update_tool_bar_sizes): New function. (update_frame_tool_bar): Remove old_req, new_req. Do not get tool bar height, call xg_update_tool_bar_sizes instead. (free_frame_tool_bar): Remove from hbox or vbox depending on toolbar_in_hbox, Set all FRAME_TOOLBAR_*_(WIDTH|HEIGHT) to zero. (xg_change_toolbar_position): New function. * src/gtkutil.h (xg_change_toolbar_position): Declare. * src/window.c (calc_absolute_offset): Check for FRAME_TOOLBAR_TOP_HEIGHT and FRAME_TOOLBAR_LEFT_WIDTH. * src/xfns.c (x_set_tool_bar_position): New function. (xic_set_statusarea): Use FRAME_TOOLBAR_TOP_HEIGHT. (x_frame_parm_handlers): Add x_set_tool_bar_position. (syms_of_xfns): if USE_GTK, provide move-toolbar. * src/xterm.c (x_set_window_size_1): Add FRAME_TOOLBAR_WIDTH to pixelwidth. * src/xterm.h (struct x_output): Add toolbar_top_height, toolbar_bottom_height, toolbar_left_width, toolbar_right_width. Remove toolbar_height. if USE_GTK: Add hbox_widget and toolbar_in_hbox. (FRAME_TOOLBAR_TOP_HEIGHT, FRAME_TOOLBAR_BOTTOM_HEIGHT) (FRAME_TOOLBAR_LEFT_WIDTH, FRAME_TOOLBAR_RIGHT_WIDTH): New macros. (FRAME_TOOLBAR_HEIGHT): Is now TOP_HEIGHT + BOTTOM_HEIGHT.

HOW TO COMMIT CHANGES TO EMACS

Most of these points are from:

http://lists.gnu.org/archive/html/emacs-devel/2009-03/msg00555.html
From: 	 Miles Bader
Subject: commit style redux
Date: 	 Tue, 31 Mar 2009 12:21:20 +0900

(0) Each commit should correspond to a single change (whether spread
    over multiple files or not).  Do not mix different changes in the
    same commit (eg adding a feature in one file, fixing a bug in
    another should be two commits, not one).

(1) Commit all changed files at once with a single log message (which
    in CVS will result in an identical log message for all committed
    files), not one-by-one.  This is pretty easy using vc-dir now.

(2) Make the log message describe the entire changeset, perhaps
    including relevant changelog entiries (I often don't bother with
    the latter if it's a trivial sort of change).

    Many modern source-control systems vaguely distinguish the first
    line of the log message to use as a short summary for abbreviated
    history listing (in arch this was explicitly called the summary,
    but many other systems have a similar concept).  So it's nice if
    you can format the log entry like:

        SHORTISH ONE-LINE SUMMARY

        MULTIPLE-LINE DETAILED DESCRIPTION POSSIBLY INCLUDING (OR
        CONSISTING OF) CHANGELOG ENTRIES

    [Even with CVS this style is useful, because web CVS browsing
    interfaces often include the first N words of the log message of
    the most recent commit as a short "most recent change"
    description.]

(3) Don't phrase log messages assuming the filename is known, because
    in non-file-oriented systems (everything modern other than CVS),
    the log listing tends to be treated as global information, and the
    connection with specific files is less explicit.

    For instance, currently I often see log messages like "Regenerate";
    for modern source-control systems with a global log, it's better to
    have something like "Regenerate configure".


Followup discussion:
http://lists.gnu.org/archive/html/emacs-devel/2010-01/msg00897.html
http://lists.gnu.org/archive/html/emacs-devel/2010-02/msg00401.html


PREVIOUS GUIDELINES FOR CVS

For historical interest only, here is the old-style advice for CVS logs:
http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg01208.html

From: Eli Zaretskii
Subject: Re: Log messages in CVS
Date: Sat, 29 Dec 2007 16:06:29 +0200