From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Moakt Temporary Email Newsgroups: gmane.emacs.devel Subject: Re: A new filter-based customization interface Date: Mon, 16 Dec 2024 22:02:42 +0000 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4843"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 17 04:21:25 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tNO9E-00015u-Mi for ged-emacs-devel@m.gmane-mx.org; Tue, 17 Dec 2024 04:21:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tNO8K-0002y9-66; Mon, 16 Dec 2024 22:20:28 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tNJZ5-0005Cx-DH for emacs-devel@gnu.org; Mon, 16 Dec 2024 17:27:47 -0500 Original-Received: from [64.31.33.50] (helo=moakt.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tNJZ3-0001eQ-E5 for emacs-devel@gnu.org; Mon, 16 Dec 2024 17:27:47 -0500 Original-Received: from tm-php.tm_tm-network ([172.18.0.6] helo=localhost.localdomain) by moakt.com with esmtp (Exim 4.92) (envelope-from ) id 1tNJAo-0000JQ-Hk for emacs-devel@gnu.org; Mon, 16 Dec 2024 22:02:42 +0000 X-Mailer: PHPMailer 6.6.3 (https://github.com/PHPMailer/PHPMailer) X-Host-Lookup-Failed: Reverse DNS lookup failed for 64.31.33.50 (failed) Received-SPF: none client-ip=64.31.33.50; envelope-from=fbb817423823@drmail.in; helo=moakt.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, FROM_LOCAL_HEX=0.006, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 16 Dec 2024 22:20:26 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:326567 Archived-At: Hi Richard, > I looked at the image you sent. I supposed it is supposed to be > self-explanatory, but as often happens for graphical interfaces, I > can't tell the meaning of what I see. > > > In order for a graphica interface to be natural and self-evident, > it should to be clear just by looking what each visual item means. > Is it an alternative you can select? > Is it a heading which describes the role of whatever follows? > Is it a command you can click on to control the interface? > These things are not clear to me. > > Here are some of the visuak aspects for which the meaning is not clear to me. > > * There is a bunch of lines at the top which start with > Filter by > 1. categoryL > interfaceL modeline tookbar,.. > general: startup quit backup... > > What do tese names mean? Are they related to custom group names? > Some of them sare names of custom groups, but some are not. > What does each of these names mean? Each name is a filter that user can select to filter on the corresponding user options. I tried to classify them using the most beginner-friendly terms, just to show the main idea I want yo communicate. When the user sees such an interface, he will also have a quick idea of what he can do with emacs, he can also immediately start discovering/trying different options. > * Is that an exhaustive list of all "categories"? I added only some, just to show the main idea. I can also think about other non-”by category” filters, for example: 1. by state: [customized] [non-customized (default)] 2. by version: .. [27] [28] [29] [to be removed in future versions (deprecated)] > * If so, are you supposed to click on one to select it? > * Or are some categories someho selexted now, and this is a list of the > ones that are selected right now? Yes, user can select a single filter, or combine (AND) multiple filters. For example user can select “completion”+”auto-save”. Each time the user select an additional filter, the list of filters should decrease, leaving only the ones that are meaningful to additionally select. And maybe also making other sub-filters (sub-categories) appear to help further narrowing the list of customizations (under “Selected Customizations:”). For example “auto-completion” filter can appear if “completion” filter is selected. With this, user can precisely find what he is exactly looking for, with few easy and understandable clicks, even with a huge number of options. > * How does the fact that a category is selected > affect what happens in the rest of this display? Each time the user select an additional filter, the list of customizations under “Selected Customizations:” will also decrease. The purpose is to quickly find the customizations relevant to a given task/behavior. > The next thing it says is > > Sort by: package > > What does that mean? Is "package" one of several psople choices? If > so, what are the other possible choices and how do you specify another choice? This should sort the list of customizations (under “Selected Customizations:”) by certain criteria. One example is “package”, another can be to list the already customized (non-default) first, etc. I added it only to keep it in mind when implementing the interface, in case it turned out to be useful to the user later on. But I can’t see it is real added value for the moment. > Then it says > > Selected Customizations: > > What does that expression "selected customizations" mean? What > determines which customizations are selected? How do you control > which ones are selected? And what do you achieve by controlling that? The list under "Selected Customizations", are the customizations user selected by applying one or more filter(s) from the above. Their is no filter selected in this image, but we can image that when user selects the “modeline” filter for example, we can either: - replace it in-place by a “modeline[X]”. - or remove it, and add a “modeline” or “modeline[X]” to a separate list of “selected filters” for example. - or keep it in place, but change its appearance (color, etc…) - etc. With this, user can know what filters he already selected, and can unselected them one by one by clicking on them again. Maybe it can also be implemented it differently. > How does this relate to M-x customize...? > It looks like the names of these things do NOT match names of user options. > > Each item and value seem to be followed by some sort of classification, > but what do they mean? They do not seem to be custom groups. > Where are they defined? For instance, two say :modeline:, What does > that indicate? Each item is a customization/option to show to the user. The value is only a single choice (I added it for demonstration), but it can be replaced by its corresponding UI element (checkbox, dropdown menu, ...) The classifications to the right are not part of the interface. I may have hidden them. I used them to “tag”/relate each entry to its corresponding filters/categories. These classifications are also not exhaustive (only some for demonstration). All the options that are related to the modeline, would be tagged as “modeline”, and will be selected/filtered when user select the “modeline” filter. Some classifications might (not) match with the actual custom groups, I tried to list them from another POV. they can be modified/adapted as needed. This interface will require each option to have multiple groups/tags. And maybe the user could be given the possibility to add his own tags (to each option, and to the interface), so he can categories, and quickly access his favorite options. > What does [X] mean? Does it mean "this is enabled"? Yes, it represents a “checked” checkbox. > If so, what indicates "this is not enabled"? An “unchecked” checkbox would be represented by [ ]. But this is not how it might look like in the final interface, it is only for demonstration. I also explained everything in details in this message https://lists.gnu.org/archive/html/emacs-devel/2024-12/msg00174.html. I also proposed a quick “Get Started” introduction to emacs (frame, window, modeline, command, etc.), so user can directly use this interface. This introduction can be added to emacs independently from the interface, because it already enhances user first experience with emacs, I post it under a different thread https://lists.gnu.org/archive/html/emacs-devel/2024-12/msg00064.html. Thank you