I agree, but what about the plugins?

Maybe we can change the plugins to work like chrome, where you can't influence the already perfect UI. You can only add a menu entry to a button placed firmly on the top far right of the window.

We could also learn from firefox, and make many improvements:

 * Make multiple plugin architectures, that all supersede one another
   but contain features, dependencies, and abilities that other method
   don't support.
 * Make the latest plugin architecture stripped and devoid of
   functionality, announcing to everyone that it the direction we want
   to go.
 * Make sure the older plugin architectures will be deprecated in the
   near future.
 * Make all of the plugins key off of the software version for
   compatibility, only compatible with minor version changes shown by
   the numbers after the decimal.
 * Change eeany's versioning to only update major versions ever couple
   of weeks, making all plugins incompatible frequently, and only the
   most diligent ones will stick around.  We want our version to jump
   as fast as possible, so we can appear to be progressing like the
   other software developers, with large numbers like eeany 51.
 * We should strip out long standing features (like firefox is doing
   with java applets and other plugins) to simplify what we support,
   with no option to keep using those features unless they modify a
   config file manually, which will go away in the next version.
 * We should warn users if a file is insecure, such as containing any
   passwords or sensitive information.  (Based on the previous email,
   we could also send the data up to HQ in clear text for our archives,
   maybe auto-mail it to this mailing list.)
 * We should change all buttons and UI elements to be very tablet
   friendly.  The bigger the buttons, the better.  Make a onscreen
   keyboard the default.  We all know tablets are the future of computers.

Learning from Gnome 3 developers, we could:

 * Hide notifications to not be as distracting
 * Allow themes in CSS, but offer little documentation.
 * Make sure there are two types of eeany code, some components using
   GTK2, others using GTK3, that run together but are not themed the same.
 * Make sure GTK3 components have no customization features out of the
   box, unless via a eeany tweak tool made and maintained by third
   parties.  The customization should be minimal, as we decide what is
   best for the users.
 * Force users to update to our latest eeany, because even though it's
   a rewrite to a whole new interface and design method, we need to
   make it as obnoxious to stay in their older version as possible, and
   require any forks to have to do any considerable rewrite to not
   conflict.

Learning from SystemD, we could:

 * Make sure there are race conditions on startup, such as requiring
   specific users and groups at the wrong times, leaving services in a
   broken state.
 * Make eeany run as a service and only log to journalctl.

Learning from Ubuntu Unity and Compiz:

 * We could strip out features we don't want but are highly popular.
 * Make sure all current developers no longer want to work on the
   project (like compiz), in favor of wayland, which any year now might
   be used by someone, somewhere, and supports rendering on the
   graphics card.  This will require a whole eeany rewrite, so we may
   as well abandon support until wayland becomes mainstream, or quantum
   computing is common, whichever happens last.
 * Put all menus on the left edge of eeany, and make them large icons
that show active features with a barely noticeable little marking. Make sure that the buttons aren't visible on some graphics cards.
 * Make any of the buttons when clicked take over the rest of the screen.
 * Any button pressed should show all features in eeany searchable from
   a search field by specific feature name.

I'm sure I missed some great design decisions, but you get the idea.

Steve


Also, learning from firefox, we should
On 03/31/2017 07:25 PM, Lex Trotman wrote:
Dear All,

Geany having failed at being a small fast lightweight IDE and having
become a chubby middle aged application, its time for a re-think, a
new direction, a fresh start.

Instead it is proposed that Geany embrace the paradigms of the most
successful IDEs (like Emacs or Eclipse) and make coding with Geany
great again.

So looking at those things that are common to Emacs and Eclipse I propose:

1) Geany should change its name to start with an E, that is obviously
neccessary,

2) Eeany should embrace the bloat, incorporate the whole operating
system like Emacs and become an overblown interfering annoyance like
Eclipse,

3) clearly using common UI conventions is important (to Eclipse) but
using custom paradigms is important (to Emacs) so it is proposed that
Eeany alternate between using normal keybindings and using randomly
selected sequences of keys.  This will make editing an adventure again
as you struggle to find the "undo" sequence.

4) Geany is far too fast, so Eeany should incorporate code to perform
bitcoin mining between keystrokes, nobody will notice, and the devs
will get rich,

5) of course great software is not just Emacs and Eclipse, so Eeany
should copy the most important of the paradigms of great software,
phoning home with copious user data which can be sold, again making
the devs rich, and clearly this should be done in secret without any
ability to cancel it, using a spawned process that continues after
Eeany exits (and restarts on boot) without any way of preventing it,
and

6) having gotten all that data it is of course essential that it be
used, so Eeany must incorporate ads, a short video selling insurance
before the compile results display, tooltips suggesting a new
toothpaste to help clean both your code and your smile.

I'm sure everybody will support this initiative to put Eeany where it
belongs in the universe of code development, at the top*.

Regards

* YMMV, press release issued 1 April 2017
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Reply via email to