Fedora's Management of its Desktop Environment and Extensions This is a feature request. I am asking the Fedora development community to overhaul its management of its desktop environment and its corresponding file manager. I am similarly requesting that the management of the enhancements currently facilitated by both gnome tweak tool and gnome shell extensions also be overhauled. The first part of this document provides the details of the request and the second part debates the merits of the request. Details ------- 1. Provide a programming mechanism that allows the (programmer oriented) user to _readily_ alter Fedora's out-of-the-box desktop environment. A reasonable first approach might be combining GTK commands with bash commands, including bash's gsettings command. If (for example) bash+GTK is insufficient, including such languages as java, c, or c++ would be reasonable. The intended timing would be that first the user does a total re-install. Then the user executes "dnf upgrade". Then the user executes his script. The mechanism should allow the user total control of a. screen resolution b. fonts c. window styles d. scrollbars e. themes f. style and size of desktop icons, including those in the next 3 items g. creating a launch menu, controlling its: (i) size (2) location on the screen h. creating a taskbar for favorite-app-icons and minimized apps, similarly controlling its size and location on the screen i. creating a system tray and allowing the user to control what items it contains, as well as its size and location on the screen j. eliminating the corresponding (now redundant) elements of the default gnome desktop k. screen-saver settings and power management settings Fedora (out-of-the-box) is probably already providing a gui for some of the above items. This suggests that scripted alterations of those particular items is unnecessary. This presumption may be false; what if a (well designed) scripting alteration disables the corresponding gui control? Providing (redundant) scripting control of those items renders this a _non-issue_. Fedora developers may decide that the scripting of some of the above items would be overly complex for the Fedora user. In that event, it would be desirable for the developers to create new utilities (i.e. API's) to facilitate the scripting mechanism. This is totally distinct from the gui-s that are currently being used to facilitate changes. The utilities would be SPECIFICALLY DESIGNED (AND TESTED) TO WORK WITH THE MECHANISM. Under no circumstances is the mechanism to involve any Fedora-spins, or any 3rd party software (e.g. dnf installing Cinnamon or dnf installing a taskbar). Script changes should be done directly against the NATIVE Fedora environment. 2. Provide a clear procedure for upgrading a "script-modified" desktop environment to the next Fedora version. For example, suppose a Fedora user script-modifies his Fedora 29 desktop environment. What happens when the user attempts to _update_ his system to Fedora 30 (rather than do a complete re-install to Fedora 30)? If Fedora-developer-testing concludes that this is a non-issue, fine. If not, the user certainly has the (undesirable) "full-re-install" fallback option. To avoid this, creativity may be needed. One approach would be to provide a script reversal procedure, so that the update is done against the (vanilla) Fedora 29 desktop environment. It should then be quick and painless for the user to re-apply his script. Note that since the modifications are done via scripting rather than dnf, dnf's transaction history would not be helpful here. An alternate approach would be to allow the user [through his script(s)] to create a second desktop environment, preserving the initial environment, and selecting his desktop environment via the login screen. In this scenario, the user could DELETE the second (added) desktop environment, THEN DO THE UPDATE TO THE NEW FEDORA VERSION, AND ONLY THEN RE-APPLY HIS SCRIPT. This approach requires the Fedora developers to provide "method(s)" that allow the mechanism to add desktop environments and then to delete any desktop environment created specifically by the mechanism. 3. Experiment to determine whether the next release is backwards compatible with the mechanism. When issues are discovered, I think that there are two reasonable reactions: a. Alter the API's so that the underlying effect is invisible to the user. This approach constitutes full backwards compatibility. b. Identify the modifications to the mechanism [e.g. script(s)] that will be needed to accommodate the latest Fedora version. Document these modifications similar to the way that Fedora is already documenting (for its latest version), What's New or How To Install. 4. Enhance the Fedora system to work seamlessly with non-native file managers, (e.g. Nemo) perhaps relying on the mechanism to make underlying changes against the native Fedora system. Presumably, only AFTER any corresponding mechanism changes, the user brings in the 3rd party file manager either through the mechanism, or through dnf. This item requires that Fedora take a hard look at what file managers are currently being used by other (prominent) Linux distros. Then, for each of the corresponding file managers, Fedora would need to question what problems it would cause in the native Fedora environment. Similar to the previous item, this item also questions whether the next Fedora version will break Fedora's support of the prominent 3rd party file managers. 5. Experiment to attempt to anticipate and resolve unusual 3rd party situations that would accept vanilla (gnome) Fedora, but barf on the corresponding mechanism (i.e. script). This includes unusual graphics card hardware &/or drivers and unusual motherboard hardware &/or bios settings. I surmise that Fedora's rolling releases are already doing exactly that with respect to the vanilla desktop environment. I also surmise that Fedora developers routinely internet-research the users' reporting of such problems on prominent forums (e.g. unix StackExchange). The idea would be to extend these efforts to include safeguarding the functionality of the requested mechanism. 6. For the mechanism, create an exhaustively documented set of pertinent TUTORIALS AND GUIDES, similar to how Java documents its swing. This way, the user can DEVELOP HIS INTUITION, learning what the relevant considerations are in altering the out-of-the-box gnome environment. The user can also learn, from a PSEUDOCODE STANDPOINT, WHAT THE PROCEDURAL STEPS ARE, AND IN WHAT ORDER THEY SHOULD BE TAKEN. My internet research has failed to discover any documentation remotely like this. WITHOUT SUCH EXHAUSTIVE DOCUMENTATION, THE WHOLE REQUEST IS POINTLESS. 7. Separately create a corresponding manual that the user can refer to ONLY TO ANSWER VERY SPECIFIC QUESTIONS, NOT TO LEARN. Again, the analogy would be the user documentation that Java provides for its classes. 8. Update the documentation (re the previous two items), with each new version of Fedora. 9. Overhaul the management of the enhancements currently offered by gnome tweak tool and gnome shell extensions. Study these enhancements to determine what commands need to be executed against Fedora's NATIVE ENVIRONMENT, AND DEVELOP A MID-LEVEL SET OF API's to facilitate the user's scripting of these enhancements. The (dinosaur) analogy would be the creation of Cobol so that mainframe application programmers did not have to program in assembler. Similar to the previous three items, have this overhaul include the corresponding documentation. Also include in this documentation a preliminary discussion of what is involved in the user developing an applet (for example, an enhanced type of clock) and locating it (for example) on the desktop or in the system tray. The discussion should include sizing and styling of the app. The idea would be to DEVELOP THE USER'S INTUITION BEFORE INTRODUCING THE USER TO THE CORRESPONDING GUIDES AND TUTORIALS AROUND (for example) NEW APPS. Similar to item 3 above, this item also involves issues around backwards compatibility. Merits ------ Obviously, this overall feature request involves enormous additional effort over a number of years, and involves an OVERHAUL of some of Fedora's software development policies. I am not suggesting that any of the current non-programmer-user facilities need to be eliminated. For example, keep the spins (if desired), continue to allow the manual (i.e. via dnf) importation of a desktop, and continue to allow the current use of gnome-tweak-tools and gnome-shell-extensions. Also, continue to provide gui control of many items listed in item 1 of the previous section. HOWEVER, AS THIS OVERALL FEATURE REQUEST IS IMPLEMENTED, TRANSITION AS MUCH AS POSSIBLE AWAY FROM 3RD PARTY SOFTWARE. In fact, as discussed near the end of this document, even the hundreds of added apps (e.g. extensions) can EASILY BECOME WELL ORGANIZED UNBREAKABLE NATIVE FEDORA APPS. Currently, there is ENORMOUS INEFFICIENCY THROUGHOUT THE LINUX (VOLUNTEER) SOFTWARE DEVELOPMENT COMMUNITY. A notable example of this, which bears discussion, is Fedora-Gnome vs Cinnamon. I surmise that Fedora's Gnome 3 is ROCK-SOLID, which I regard as critical. This is part of what makes Fedora attractive; its default desktop environment, coupled with its default file manager, DOES NOT BREAK. However, user-desktop-environment desires will always vary widely. Further, hardware IS ALWAYS GOING TO BE CHANGING. Also, Fedora is ALWAYS GOING TO BE REACTING TO THIS AND CREATING ONE NEW VERSION AFTER ANOTHER, with the ongoing challenges of backwards compatibility of Fedora with ANY 3rd party software. Further, with so many Linux distros, each with its own native environment, it may be very difficult to create AND ENFORCE Linux-Industry-Wide standards on such things as 3rd party desktop environments. This suggests that (for example), the gulf between Cinnamon and Fedora's native environment MAY SIGNIFICANTLY INCREASE. If my approach had been taken 10 years ago, then (arguably): 1. Cinnamon.Org would never have come into existence. 2. Fedora would have used the features that I am requesting AS THE BASIS for creating and maintaining its own Cinnamon spin. 3. Similarly, Fedora would have developed its own native Cinnamon package that is installable via dnf. 4. Hardware and software glitches around a third party desktop environment would be totally avoided, because THIRD PARTY DESKTOP ENVIRONMENTS WOULD NEVER BE USED. 5. The programmer-oriented user, who opts for doing his own customization, would also be TOTALLY USING NATIVE FEDORA SOFTWARE. 6. This means that Fedora would remain ROCK-SOLID, regardless (for example) of the desktop environments used or customized. The whole point of this document (with respect to the desktop environment) is to SEVER ANY DEPENDENCY THAT EITHER FEDORA OR THE FEDORA USERS HAVE WITH ANY 3RD PARTY SOFTWARE. Typically, the new linux user will veer towards a Linux distro that is: a. Simple to install b. Simple to use c. Provides a gui that the user is already comfortable with In my opinion, Fedora's installer is GREAT. Although the new user MAY react negatively to the initial VISUAL impact of gnome, this can be addressed through extensive online (very easy to understand) documentation that the user is DIRECTED TO DURING THE INSTALL. A new user will have no problem clicking a link and having the browser then open to the corresponding documentation. Then, the documentation can provide discussion, WITH ILLUSTRATIONS, of various canned desktop environments that it is offering (each ROCK SOLID, RE THE PREVIOUS SECTION), AND PROVIDE THE NEW USER WITH A PICTORIAL GUIDE TO OPENING THE COMMAND LINE INTERFACE (i.e. Bash), AND USING DNF TO INSTALL A DIFFERENT (but Fedora native) DESKTOP ENVIRONMENT. FURTHERMORE, FOR THE MANY USERS INCAPABLE OF USING (for example) BASH or DNF, THE ONLINE DOCUMENTATION ALSO DIRECTs THE USER TO A SPIN. This means that the online documentation is giving very clear instructions to the new user about IMMEDIATELY RE-INSTALLING FROM SCRATCH, BUT USING A SPIN INSTEAD. Fedora can have its cake and eat it too. It can EASILY attract users away from Mint or Ubuntu (for exampleS), offer (EASILY scripted) UNIVERSAL desktop environment customization, AVOID ALL desktop environment backwards compatibility issues, and USE THE SAME EFFORT MADE IN PROVIDING PROGRAMMATIC UNIVERSAL CUSTOMIZATION TO (INTERNALLY) QUICKLY AND EASILY MAINTAIN BOTH ROCK SOLID SPINS AND ROCK SOLID DNF-DESKTOP-ENVIRONMENT packages. With respect to managing variations in the desktop environment, the file mgr, the update process, and backwards compatibility issues, DOES THIS DOCUMENT REPRESENT THE FUTURE? ................ The inefficiencies in (for example) managing the hundreds of offered extensions is in one way not as bad, and in one way worse. Inefficiencies arguably not as bad, because the extension is often written specifically for Fedora, and while the extension might be broken today, at some point in the past it worked. The inefficiencies are arguably worse because: a. Typically the original author/contributor will stop supporting his app. b. I surmise that the app is typically written in a low-level language that even the (internal) Fedora developers may have trouble with. c. I surmise that no quality control standards are implemented on an extension. This means that there is no documentation in the code that explains how and why the author used specific methods. d. I surmise that there is no effort made to ensure that moving from one version of Fedora to another does not break the app. e. I surmise that there is no ORGANIZATIONAL-QUALITY-CONTROL, which means that redundant or closely related apps appear, making it difficult for the user to see the forest for the trees. Suppose that a mid-level Cobol type language is implemented, that applies to extensions as well as desktop environments. Further suppose that Fedora REQUIRES that 1. New apps are (Fedora-internally) quality controlled re code well structured, code uses the mid-level language rather than a low-level language, code is (very) well documented (with Fedora-internal addressing code documentation as needed), app fits in to the (Fedora-internally-maintained) organization of apps. 2. Then the app is using NATIVE-FEDORA software only, so the APP SHOULD NEVER BREAK. 3. Immediately after the app is written, it is turned over to the Fedora developer community for management/maintenance. With high quality code, this means that even if the original author disappears, the app will always be usable. 4. This also means that once the app is brought up to high quality it will ALMOST NEVER REQUIRE MAINTENANCE. This approach (with the app being open source, in a mid-level language) means that the (programmer-oriented) user can EASILY further customize his own private copy of the app. Naturally, the (sophisticated) potential contributor of an app will balk at what he feels are egregious requirements. True, and unavoidable, but offset by two factors: a. Programming the Cobol-type language will be easier, thus encouraging new contributions. b. If Fedora-internal publishes VERY CLEAR standards of what is required before a contributed app will be "acceptable", it will FEEL somewhat less burdensome to the potential contributor, because he can more easily maintain a high quality as he codes. After all, as he is coding, HE KNOWS WHAT THE STANDARDS ARE. With respect to managing extensions, DOES THIS DOCUMENT REPRESENT THE FUTURE?