Apparently, the email that I sent (below) was mis-directed. Sorry for
the mistake. I was advised to send this email to you.
--------------------------------------------------------------
I posted a query to https://ask.fedoraproject.en asking how to communicate a feature request to the Fedora developers. I was told to send this email. I have included the detailed request as an attachment to this email.
If this email is misdirected, and you want me use an alternate communication channel, please email me. Also, if you have any questions, or if anyone wishes to engage me in a challenging discussion, you are also welcome to email me.
Steve Schooler
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?
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
