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