Moving around Arduino IDE source files

[Matthijs Kooijman]

Hey folks,

after working with the IDE code for a while, I think it might be good to
move around some java source files in the IDE, to make things a bit more
easy to navigate and easier to find your way around the java code.

While discussing this with Cristian, he convinced me to try a proper
IDE (using vim so far), which should make it easier to find source files
regardless of where they are, but I still feel that having a cleaner
structure would be beneficial, especially to make it easier for people
to look around the code and contribute.

I have some ideas on how to improve the file layout, and I would like
some feedback on these.

Currently, there's basically four places for java code, divided in two
ways:

- There is app/src vs arduino-core/src. This divides GUI code from
core (non-GUI) code, which is a useful distinction.
- There is a processing.app and cc.arduino package. This roughly
corresponds to "old" code from processing and newly added classes. I
do not think this distinction serves any purpose (anymore), the code
has deviated so much it's just effectively Arduino code now.

Both of these divisions apply to all code, so both the app and
arduino-core directories contain classes in the processing.app and
cc.arduino packages. This makes it hard to find a specific file, since
the package name does not tell you in what directory to look. This also
has consequences for the access control: because the gui and core code
live in the same package, they can access each other's protected members
as well, which I think doesn't really promote good encapsulation.
Furthermore, the GUI vs non-GUI distinction only lives in the
filesystem, not in the java package structure.

My proposol would be to:
- Rename all processing.app classes to cc.arduino, to have a single
base package for all code.
- Split the code into a gui and core package to separate GUI from
non-GUI code. e.g. cc.arduino.core and cc.arduino.gui.

This would solve the above issues and make the code layout a lot more
predictable and consistent.

This is mostly a mechanical change in the package and filesystem
location of classes and should not change the contents of any source
files, other than to update references and make some members in the core
package public (which were previously protected, but still accessed from
the gui code).

I already tried doing this using Eclipse's refactoring feature, which
works well enough with a bit of fiddling. It also seems that git
understands all these renames well enough to allow rebasing existing
commits on top of this change with ease (only changes to import lists
will result in easy to fix conflicts, of course).


I'm also pondering about merging the app/src and arduino-core/src
directories, so there needs to be only a single top-level directory
containing all java sources. However, merging these into a single source
tree would allow the core code to access the gui code, which is currently
prevented (and should be prevented). Some fiddling with ant and/or
eclipse might allow compiling core and gui seperately, but I'm not
entirely sure if that can be done reliably (probably for ant, probably
not for eclipse).

One alternative would be to just add a top-level directory. When also
renaming the projects to match the packages, that would give
src/core/src/... and src/gui/src/..., so still two separate projects, but
one top-level directory. Using src twice is a bit weird, though. Perhaps
source/core/src and source/gui/src is better? Any other ideas?

If we stick to two separate top-level directories, does it make sense to
rename these to match the packages too? So arduino-core -> core and app
-> gui? I don't really think the current names completely reflect the
distinction between them.

Gr.

Matthijs

[Massimo Banzi]

Hi thanks for the well research email!

I think re-factoring the IDE code could be a good idea at this point.

do you think it would be good enough if the two packages were something like this?

cc.arduino.ide.core.* and cc.arduino.ide.gui.* (while we’re refactoring the code it might be good to add .ide. so that we separate IDE code from any other java code we might have.)

you would have two separate folders under the cc.arduino.ide.* folder structure but only one src directory…

BTW do you think this change will break IDE plugins (tools) which rely on the processing.app packages?

m

> --
> You received this message because you are subscribed to the Google Groups "Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

[Matthijs Kooijman]

Hi Massimo,

> do you think it would be good enough if the two packages were something like this?
>
> cc.arduino.ide.core.* and cc.arduino.ide.gui.* (while we’re
> refactoring the code it might be good to add .ide. so that we separate
> IDE code from any other java code we might have.)

Ah, excellent idea.

> you would have two separate folders under the cc.arduino.ide.* folder structure but only one src directory…

That's what I'd ideally see, but it might be hard to enforce that core
classes cannot reference gui classes if you put all the code in a single
src/ directory (e.g. a single ant or eclipse project/module).

> BTW do you think this change will break IDE plugins (tools) which rely
> on the processing.app packages?

Ah, good point. This crossed my mind at some point, but I forgot to
write it down. Since this change would really rename *all* classes, this
will almost certainly break all of those plugins. I'm not sure if this
is much of a problem, since I haven't really more than one or two of
these plugins in practice. Also, no real attempt to define a proper API
for them has been made AFAIK and no attempts are made to preserve API
stability.

I considered keeping the old class names around (as empty classes
extending the new class names), which *might* keep some plugins working,
but this is far from perfect and will probably just break in less
obvious ways. I had a quick look if there is some way to define aliases
for classes / packages in Java, but I couldn't find anything (there's
"jarjar" which allows automated renaming of classes in a .jar file, but
I don't think that fits the bill here).

Gr.

Matthijs

[L. M.]

That is quite the proposal... something I would understand in its current formulation if we were 10 years ago and the state of Java development were not as mature as it has become, or if I knew that it came from a first year computer school student will little real-life large scale application design experience yet. I sincerely hope that someone in the core team with software design experience will take the time to review the details and find the right analogy to explain the issues. IMHO this is not what will help Arduino stay competitive against the flurry of professional offers out there.

Cheers

LM/

[Paul Stoffregen]

This may not be a popular opinion, but I feel any honest conversation
about making the source accessible for would-be contributors needs to
discuss the trend of increasing complexity in the code base. The
unpleasant reality is Arduino's internal code complexity has massively
increased over the last few years, to the point where it's nearly
impossible for new contributors to get started with the IDE. If
rearranging folders and files helps at all, it'll make only a slight
improvement.

I've followed the IDE development closely for 7 years. During that
time, I've noticed 4 eras of complexity.

1: Long ago, nearly all data was manged by the Processing preferences,
which looks up a value for string keys. Keys were made by string
concatenation, with different systems prefixing their names. This was
very easy for would-be contributors to understand, especially because
the strings matched up to the contents of preferences.txt. The code was
usually compact and self-contained, which is easy to understand when
getting started. Arduino didn't support more than 1 boards.txt, but
multiple boards and cores were supported.

2: When multiple hardware directories and separate boards.txt files were
supported, the code base started transitioning to Java maps. The
concept of a single hierarchy was replaced by maps for targets, which
mapped to boards, and then to cores, and eventually to variants.
Simple, easy to understand data types like "String" were replaced with
types like "Map<String, Integer>" or "Map<String, Target>" or even
"Map<String, Map<String, String>>", which makes the code quite difficult
to read. As these Map types became pervasively used as types for
function inputs and return values, and lots of different and separate
Map structures were used for many different purposes, Arduino lost the
simplicity of a text-based file which corresponded to recognizable stuff
in the code base. It became necessary to keep a mental model of what
all these various maps did, and be able to deal with the much more
complex Java syntax these maps require.

3: In the 1.5 development, as more and more maps were added, the third
era of Java class abstractions began. Nearly all these map types were
converted to Java classes. Some add little more than giving the map a
name, but many do add code. Many aren't maps, but encapsulate a small
amount of data. A tremendous number of these exist now.
LibrariesIndex, LibrariesIndexer, ContributedLibrary,
LibraryWithNamePredicate, LibraryInstalledInsideCore,
ContributionsIndex, ContributionsIndexer, ContributedTargetPackage,
ContributedPlatform, PlatformArchitecturePredicate,
HostDependentDownloadableContribution are just some you might try
reading to figure out how Arduino 1.6.x does something with managing
libraries. Almost none of them have comments explaining their purpose
or rationale. For example, you might look at ContributedTargetPlatform,
only to discover it has almost no code (and no comments explaining what
its purpose is), but it inherits from LegacyTargetPlatform. Then you
look at LegacyTargetPlatform, which does have lots of code (but again no
explanation of what it is or does). It does have a couple Map lists,
and it inherits from TargetPlatform, which appears to be an abstract
class. Most of the functions return Map types. Every one of these
classes was probably created with some good reason, but there are so
many of them, and in so many cases they don't encapsulate functionality
like you'd expect an object oriented program to do, but rather provide
references to Map types, which makes the code very complex and difficult
to understand.

4: Starting with 1.6.6, we now seem to be moving into a new era where a
good portion of Arduino's functionality has moved to a separate code
base, in Google Go language. Now a contributor needs to not only
understand Java and the finer points of complex Map types in Java, but
now Go language as well. The new builder code continues the tradition
of a large number of classes to understand (many with only small amounts
of code), with little or no documentation about their purpose or
rationale. Even the program's structure takes these abstraction levels
to new heights, with separate objects to collect up variables, which are
passed from object to object, making it quite difficult to follow what
data is actually input and output by each part of the program. Even the
order running functions in sequence is done by an abstraction layer of
lists of function references, rather than normal code that simply calls
the functions. Having two difficult code bases to learn in 2 languages
really raises the bar for anyone to learn the code well enough to do
something really useful.

My long-winded point is Arduino's code base has grown very, very
complex. Admittedly, the IDE has become very configurable. But still,
the trend towards more and more classes and abstraction layers, and the
trend to pass complex data sets around, use of complex types & syntax,
and now 2 languages... it all makes the code base astronomically more
difficult for would-be contributors to come up to speed and do anything
productive.

Rearranging files and folders might help a tiny bit, but doing so is
really ignoring the reality that the code itself has become very complex
and unapproachable, regardless of how the files are arranged.

If you really want to make the code base more approachable, work needs
to be done to document the purpose and rationale behind the many
classes. Future development should consider the cost in complexity of
adding more abstraction layers. Ideally, more object oriented design
principles could be adopted, to encapsulate data and functionality
within objects, rather than provide public functions which effectively
make all the object's private data public by providing Map references.
Effort should be made to avoid very complex Java & Go syntax, using
simple types for function inputs and returns. Above all else, there
really needs to be documentation created to explain what these many news
classes do, and why they do it, and how each fits into the overall
working of Arduino.

[Matthijs Kooijman]

Hi Paul,

thanks for your thoughts, and the historical perspective. I totally
agree that the current code is more complex that it should be to allow
(new) contributors to find their way (old contributors as well). I also
suspect that it is more complex than it needs to be to support what it
does now, but only actually trying to simplify it will prove that :-)

I have some other thoughts about cleaning up and simplifing the
codebase, but wanted to put this proposal out there first, since it is
the most invasive (in terms of files modified, anyway). So expect more
later :-)

Gr.

Matthijs

[L. M.]

I am looking forward to seeing how much code can be simplified using VIM as an editor. Don't get me wrong, I use VIM myself... for simple scripts. And I think this is the issue underlying the evolution of this application. The people who wrote Processing (and this equally applies to Nodes or even Atom) had some sense of software design, and how to structure their thinking into small leak-proof abstractions that interact with via small 'surface' of contacts. Unfortunately over time the current codebase has lost much of the initial boundaries, and code has started to show-up wherever the person writing it could drop it and still have the application work. IMHO the code is not complex (in the sense of levels/kinds of abstractions that are difficult to grasp), it is actually quite simple, too simple if you ask me (in the sense of lacking structure and looking like an overgrown bash script), but more importantly parts look like they have been written as long streams of consciousness with little to no true structure.

As I write these words, I realize it is a entirely futile to try to preach for more explicit logic and structure when an arduino-builder written in GO can be viewed as a logical next growth step to improve upon the former Compiler.java. Although it is true that anything written in GO represents 100% job security for the programmers, there might be a good reason why the language does not appear in mission critical enterprise projects. We all know that with enough patience and keystrokes, there is no heuristic that cannot be turned into a working sequence of computer instructions (I guess the hardware analogy is that with the right amount of patches any bad board can eventually be made to do something). There is no doubt that arduino-builder works, but should all things that can be made to work actually be written?! 

Aside from its job-security aspect (it is probably not long ago that all the people having heard of GO could fit in a single room), I did find the script well written (in the sense that there is a lot things put together that manage to find eachother at the right time and that the files are quite easy to read), but ultimately poorly designed (but nobody should take my word for it, and instead verify for themselves - interestingly enough, the last time I extended a similar invitation was in a professional situation and it led to a $4.7M project being phased-out after an independent external review made my warnings sound like child play). That said, I realize that as a company there may be good reasons for wanting to do things that no competitor does, but I am very curious to find out if writing giant GO scripts is one of them.

OO Design has been around for 30 years now, and yet I think it is still not understood by most of us. Unfortunately though I think it is here to stay because it has demonstrated that it is the only possible way to deal with large amounts of code over long periods of time.

Thank you for your patience with my diatribe, and best of luck for the revamping.

LM/

[Massimo Banzi]

Laurent

Please take this message as an attempt to encourage an healthy discussion.

We welcome your input as we would like more developers to provide constructive feedback.

Having said this your last emails are long rants that make it difficult to distill a positive, constructive contribution to this discussion.

Moreover please refrain from referring to people as “first year computer science students” it only creates animosity without actually providing any actionable feedback.

This kind of negative approach to communication might be the norm in more “conventional” tech oriented forums but this is not the Linux kernel mailing list.

Please be awesome to each other.

I welcome any positive proposal from you at any time.

thanks!

m

[Massimo Banzi]

Paul

As always thanks for you well researched feedback.

I can only summarise some of the logic behind the choices we made:

1. We spent years feeling that we needed to have a much better user experience. Adding a library by unzipping a file seemed very simple in 2005 but in the end we found a LOT of areas where we needed to to better. I believe Federico Fissore has done an exceptional job at adding all those UX improvement and with Cristian they make the IDE leap ahead in terms of functionality

2. The community wanted more configurability. This has created an healthy ecosystem of people who have packaged up support for several different boards and processors. so we made the IDE more open for the community.

3. Same goes for the compilation phase. We wanted a lightweight tool that could run as a single binary on multiple platforms (ARM included) with a “more scientific” way to process the .ino code and extract prototypes etc.
I encouraged the developers inside arduino to come up with a language they could use in multiple contexts (devices, web etc)
The choice was go. This wasn’t easy and I can tell you that some people didn’t like it (Normal in any team..).
I think the arduino builder is a great addition to the ecosystem, It allows people to compile code from the command line using the same engine as the main IDE so if VI or Eclipse is your tool of choice you can use it knowing you’re going to get the same results as the official IDE. I think if we had chosen C++ maybe we would have had a lot more trouble getting it to the same level it is now in the same timeframe.

3. Complexity
When you improve UX the code becomes more complex. still I believe we haven’t even remotely reached the level of complexity of something like Eclipse…
Debugging is the next big addition and that is going to add more complexity.
I do agree with you that we need better documentation for developers and we should hire somebody from the community to do that (maybe finally using the BountySource account we have)

More suggestions for a better documentation of the IDE code are welcome

m

[L. M.]

I can see how my words could have been chosen differently... My intention was to find a image that could convey the gap I perceived between the issue at hand (we are all in agreement that the is a code quality/clarity deficiency) and the formulation of a solution negating many years of advances in Java development.

Ultimately, unlike many legacies of past generations, it seems ours will be that all software we produce is expandable. And as this industry matures, it seems that the cycle is accelerating, leaving us with more and more write-and-throw code. This is of course not true across the board, and there are plenty of large scale projects the structure of which has allowed them to survive the test of time. But they all have one thing in common: structure and abstractions. The right amount to create containment areas, but not so much that they can only be contributed to by theoretical physics phd candidates. I have tried to share how IHMO the codebase has clearly painted itself into a corner, but not yet, I believe, to the point where any movement forward is bringing the app closer to self destruction.

I realize that I only started playing with the codebase a month ago, which might create a credibility gap when exchanging opinions with people as familiar with the project as you all are. This was part of my decision to share snapshots of a working IDE, rather than simply put forward arm-length change requests. I already shared a number of these for some of the simple features I created along the way and added a couple here (don't mind the replicated icons, there are for features I did not yet have the time to design proper icons for - actually none of them are usable but they are java code generated from SVG ... I am just very bad with design software). What no screenshot can tell is that all these enhancements are now packaged as extensions, meaning that if I remove the jars from the classpath you would not see any differences with your IDE (except for the internal code cleanup that makes them possible). 

The point is not what I have done in a month, but to show that many things are possible... at a low cost for now, debugger being one of them. I intimately believe that none of what we write is hard, and we all know that if we pound a keyboard long enough, a debugger, or some sort of code completion, or anything else for that matter,  will eventually turn-up. The real difficulty is how to do it with the lowest cost/efforts, and without making the next enhancement (like but not limited to the ones I made) an order of magnitude harder to accomplish. I have a deep admiration for Brian Goetz who summarizes it very well: today's problems are yesterday's solutions.

IMHO there is a fast approaching cross-roads ahead, and regardless of how the message is delivered, the fact remains that the statement is either true or false.

@mbanzi  "we haven’t even remotely reached the level of complexity of something like Eclipse" I have done a lot of work on the eclipse codebase and IMHO it is easy to work with because of its high degree of cohesiveness. I think it is not for no reason that Erich Gamma was both the father of eclipse and a co-author of the seminal GOF book on patterns (btw, he is now at MS working on their new coding libraries... and it shows)

[Paul Stoffregen]

Massimo,

Indeed Arduino has developed tremendously over the last few years. You
guys have done really amazing work, especially to support such a wide
range of hardware from so many 3rd parties. You're correct that complex
features do require more complex code. Some of the increase in
complexity is unavoidable.

My only point is the code has grown perhaps more complex than
necessary. In particular, the practice of essentially making most of
the private data of objects public with getter functions that return Map
references is not good. Neither are data container objects that
essentially make large collections of variables global scope. Likewise,
an excessive number of abstraction layers only makes things harder
rather than simpler to understand.

From the tone of your message, it seems you believe this increasing
complexity is all absolutely necessary. Some certainly is. Perhaps all
of it really is needed? Maybe this really is the best way?

You guys really do know good design. That's what's made Arduino so
successful, intentional design that makes technology simpler. I only
hope you'll take an honest and objective look at how you're designing
the software itself. Rearranging folders/file locations and outsourcing
documentation to 3rd party writers feels like ignoring the issue.


-Paul

[L. M.]

@paul I admire the patience you put into explaining in details what I was hastily covering with the blanket statement 'absence of visible structure'. The syndrome you eloquently detailed is what Josh Bloch (of java fame) summarizes as "leaky-abstractions". OOD has been around for 30 years, but it still is its biggest pitfal...

GO is like any other language, a tiny set of vocabulary and conventions used to convey heuristics... neither intrinsically good nor bad. The difference is what we do with it. Might be useful if a software/hardware wizards could find the right analogy to convey graphically in hardware design terms, the equivalence of what this code and the initial proposal that started this thread are to software.

very best,
lm/

LM/

[L. M.]

attached improved support for AVR assembly syntax highlight... 

IMHE renaming is more productive if done last (lesson learned from doing 250KLOC+ codebase refactorings). A more productive first task would be to start re-assembling related code that is presently spread in different parts of the UI. Aside from increased clarity, many changes will become simple incremental steps... there is a goldmine of them laying around in the codebase

[L. M.]

I welcome any positive proposal from you at any time.

I do appreciate the sentiment. This is how I started a months ago, maybe to doing it via linked-in (for the extra background info it provides) was not such a good idea though. 

Very best,

LM/

[L. M.]

Massimo, Cristian, Federico

Paul did a great job of describing what it seems a number of us feel is the issue with the source code for the IDE project. To be even more specific, here is a tiny piece of code that will illustrate a principle I will elaborate on later:

          String serialMinusChar = serial.substring(0, serial.length() - 1);

          if (computedDevicePath.equalsIgnoreCase(serial) || computedDevicePathMinusChar.equalsIgnoreCase(serialMinusChar)) {

           return (device.get(VID) + "_" + device.get(PID)).toUpperCase();

         }

It is a small piece of the USB probing code on OSX. The goals of the routine it comes from, is to parse through the output from a OSX system command, look for a given device, and return something that will then be used to match with the contents of the boards.txt file. First problem: you have to take my word that this what the routine does, because nothing in the concatenation explains that this is a identifier. Second issue: the string pasting is fragile because it assumes a convention (all upper case id) that is not explicit or documented. What's worse about this convention is that on the other side (where board.txt is read), nothing is done to follow the same convention, leaving board.txt creators responsible for having to follow a rule (vid and pid MUST be all caps) that is by no way obvious. Third issue: the convention that the identifiers will be of the form VID "_" PID is in at least two places.. Things as critical as the unique way to identify a device should not be sprinkled across the codebase, but made clear and self documented. Classes in java are dirt cheep and the foundation of OODESIGN is to use object to convey semantics. Without an object, it is hard to track things through the codebase or even decide on heuristic changes with the certainty that they will not introduce regressions (good luck ever trying to switch VID and PID around - not that someone should, but if the code was cleaner, it would not represent such a high risk of failure).

At this point there is a real danger that the tree will hide the forest and that we will embark on a discussion about whether or not a simple value object like TargetBoardIdentifier should or not be created. That is not the point. I picked this example because it is simple, easy to track, and trivial enough that it fits here. The point is that the same issue is present at many different scales throughout the codebase: many key notions are hidden behind impossible to track (I am talking about AST tracking) hashmaps, and the ones that are described with objects are often leaking their abstraction throughout. The examples abound:

 Editor/Sketch/SketchData/SketchDocxxx, or Compiler/EditorConsole/EditorStatus/XXxStream to only mention two. 

The Github issues list is full of requests that in the present circumstances must feel like economically un-justifiable risks. I don't think it is fate. By simply untangling these clusters, in the space of a month I was able to address a number of them while adding a number of my own: navigation view, lib editing, stoppable compiler, per-editor console output, multi compilation errors reporting, 2 selectable compiler backends, multi file types support with syntax highlight and completion (c++ not complete yet), global search, complete app skinning, integrated help browser and a few more. For the most part, cleaning up the codebase usually means copy/paste/adapt and add abstractions. But again, my enhancements are just the tree, the forest behind is that the codebase is a lot more manageable, and less scary to think about enhancing.

As Paul concluded, rearranging folders/file locations and outsourcing documentation to 3rd party writers feels like ignoring the issue. I will add that depending on how it is done, there is even the possibility of making matters worse.

-LM

[Matthijs Kooijman]

Hi Laurent,

> As Paul concluded, *rearranging folders/file locations and

> outsourcing documentation to 3rd party writers feels like ignoring the

> issue*. I will add that depending on how it is done, there is even the

> possibility of making matters worse.

AFAICS, I've provided the details of how I'm proposing it to be done. If
you feel that my proposal would make things worse, I would invite you to
speak up and explain why. If you have another opinion on the actual
proposal at hand, feel free to also let me know, so I can possibly
improve the proposal.

Gr.

Matthijs

[Paul Stoffregen]

On 12/06/2015 12:48 PM, Matthijs Kooijman wrote:
> AFAICS, I've provided the details of how I'm proposing it to be done.

I'm just re-read your proposal, from Dec 2nd. Actually I've read it a
few times. I get the general concept, or at least I think I do, but
quite frankly the details are unclear (at least to me). Much of my
confusion comes from the last 3 paragraphs, which discuss a variety of
alternatives and several (perhaps rhetorical) questions.

Really, it's not critical that I know every detail of your plan. You've
consistently done good work, so really all the matters (at least to me)
is you've thought this through well.

> If you feel that my proposal would make things worse, I would invite
> you to speak up and explain why.

Almost all major changes involve a short-term cost for a long-term benefit.

Initially, this absolutely will make things worse! All existing patches
will break. Even if git automates dealing some of the issues, everyone
involved must have sufficient git knowledge and experience. Even if
tools automatically convert all existing patches, there's still the
human cost learning the new structure.

Presumably it will be simpler, for a long-term net savings after the
initial pain of adapting to the change. Personally, I'm skeptical *any*
mere rearranging could make much of a difference, given the way the code
is designed (or rather, has evolved).

But the last thing I want to do is be an obstacle to change. To
whatever extent my opinion matters, which realistically isn't very much,
I want to welcome any bona-fide effort to improve and simplify the
code's structure. Incremental progress is better than no progress!

[Matthijs Kooijman]

Hey Paul,

> I'm just re-read your proposal, from Dec 2nd. Actually I've read it a few
> times. I get the general concept, or at least I think I do, but quite
> frankly the details are unclear (at least to me). Much of my confusion
> comes from the last 3 paragraphs, which discuss a variety of alternatives
> and several (perhaps rhetorical) questions.

Right, there's really two parts to the proposal: Re-arranging the code
into arduino.cc.ide.gui and arduino.cc.ide.core packages (note the added
.ide. as suggested by Massimo), and rearraning the arduino-core/ and
app/ directories. The former seems clear-cut to me, the latter, I'm not
so sure (and opinions on the various alternatives are welcome).

Gr.

Matthijs

[Matthijs Kooijman]

Hi folks,

On Wed, Dec 02, 2015 at 06:17:25PM +0100, Matthijs Kooijman wrote:
> I have some other thoughts about cleaning up and simplifing the
> codebase, but wanted to put this proposal out there first, since it is
> the most invasive (in terms of files modified, anyway). So expect more
> later :-)

It has taken a while, but here's the cleanups I was talking about then:

https://github.com/arduino/Arduino/pull/4363

Comments and reviews welcome, of course.

This cleanup doesn't address the points Paul raised (complexity in the
handling of preferences and third party cores, boards, etc. IIRC), but
improves the handling of sketches and the editor.

Gr.

Matthijs