The path to a future proof implementation of Eclipse SWT lessons from initiative 31

This talk discusses Initiative 31, aimed at evaluating the future of the Eclipse SWT framework to enhance its sustainability, maintainability, and user experience. The speaker explains the project's background, addressing pain points such as outdated UI design and the challenges of maintaining separate implementations across multiple operating systems. Emphasizing an OS-agnostic approach, they explore potential technologies like Skia for building a more responsive and customizable UI. The speaker outlines the prototyping phase results, focusing on the team's incremental progress toward developing a unified implementation while ensuring existing applications remain operational. Finally, they highlight future steps and necessary resources to achieve a production-ready state, along with lessons learned from the initiative.

All right, welcome to the last presentation today and thank you all for your interest in the future of Eclipse SWT. This presentation is about the project initiative 31, which aimed at evaluating options for sustaining the future of I've given a presentation about this project already at last OCX, which was about an intermediate state of that project back then. This one now is about the final results, about

the takeaways and the lessons learned that we um gained from this initiative. Um Dennis has already given a presentation yesterday about a very specific uh result or follow-up of this project. This is more the broader picture of everything that we did in this project. First question to all of you, as far as I can see you now here in the light, who of you has already heard

of initiative 31? Okay, that's almost everyone. That's of course great. Still, I will of course give an introduction to the project, why we did that, uh the the first step that we did also until last OCX, just to be all on the same track and to recap some stuff that you um might have forgotten already. So, let's first start with why we did this project at all.

So, what were the the pain points that we saw? Why did we think SWT needed or needs any change? So, what we're talking about is of course products built on top of Eclipse SWT. That's usually products using the Eclipse platform. Um there are thousands of such products out there, which were which we know about. This one is the tool provision that we develop in one department at

Vector, which is for the holistic design complex software defined systems, for example, electric electronic architectures from requirements over architecture down to the wiring harness. So, very large product, like many products built on top of the Eclipse and yeah, in this department we also do some Eclipse development. So, we're based on this platform. So, we do contributions to the platform. We have a small team doing that, which

I'm part of. And yeah, and in that um yeah, domain we uh investigated this project, this initiative 31, uh driven by the fact that um particular this is a Windows-only product. So, Provision is currently only built and deployed for Windows. And in particular, Windows has some specific pain points, but we have some pain points in general that do not only affect Provision, but actually any Eclipse-based product.

First one is um in this case also for the Eclipse IDE. For example, if you talk to people using the Eclipse IDE, if you take a look in the internet, what you find is complaints about the look and feel of this, about the UI, and how it can be configured. So, usual pain points are that or concerns are that the UI looks outdated, looks old, um which

is not that much a surprise because we're still using the same UI library that was used 20 years ago when SWT was implemented on Windows. So, there are more modern libraries on Windows, but we still use a an older one, which makes it not look like a modern native application, but rather an an outdated And even though we have theming capabilities in Eclipse, it's not that easy

to really match a corporate branding, to really make an application look like it fits into your corporate applications. Uh so, that's another pain point in terms of look and feel uh that you have with Eclipse-based products. So, it's about yeah, the look and feel being controlled by the OS, not by the application. You cannot apply a uniform corporate branding, and about the customization, which is even limited

to what you can do on all supported operating systems, so Windows, Linux, and macOS. Uh so, one thing where we just recently, last week or week ago, um had issues with this being controlled by the OS is the macOS implementation, which we started to build against newer SDK, and new Mac OS version. And what then happened is that we got a broken broken UI. So, what you

see here, it looks okay, but actually all these numbers that you see on the right are text boxes and probably you would you wouldn't have guessed that those are text boxes where you can enter stuff into it. Rather looks like labels. That was one of the issues because colors were suddenly changed. Uh some widgets didn't even react anymore. They didn't update their contents anymore. So, this was

just because we used the new uh uh Mac OS SDK against we which we've built that. And this is the second burden that we have all the time, the maintenance of all this because the operating systems that we use evolve. We have to adapt all the time to the changes in the APIs and the implementations of the libraries of the operating systems. And another part is if

you add new functionality to Eclipse SWT, you have to do that three times. So, once for every operating system, you have to implement that three times, test I do something like that. I have my Windows laptop, I have an other Linux system, I have a MacBook, so that's really much effort. You many resources um many competencies to do that. So, uh this is a screenshot from the

bug tracker in SWT. If you just filter for the labels for uh operating system specific issues, they do not even cover all of them, but currently we have 150 open ones and they're accumulating all the time. So, it's just an indicator that we have OS specific issues all the time that we yeah, that we hardly can address uh when they occur. So, maintenance is larger issue that

we have, keeping all the three implementations up to date and working. the thing is that these two pain points that we see basically affect all major Eclipse based products. At least either of these pain points affect basically every product as it affects on the one hand the users or adopters of the platform and on the other side the maintainers that um yeah, maintain Eclipse SWT. And it's

one of the most common and severe challenges that we see for all Eclipse based products. Of course, there are other challenges as well. We have for example, some responsiveness issues that you often see when using the Eclipse platform, but this one is really common to basically every Eclipse application. And this was a driver back in 2024 in the Eclipse IDE working group when we were discussing with

the companies in there. So, they all want to sustain the Eclipse platform for their products. Those are the currently um the companies currently being in that working group. We discussed what we can do together. So, where are really pain points that none of us can address on their own, but we can do that as shared shared effort. So, I had a vision that we want to work

towards together. And we then decided when yeah, comparing it to other challenges that we see that this one is the the thing that we agree on a yeah, future-proof implementation of Eclipse SWT for the sustainability and maintainability of that library. So, what we then did is to yeah, find out what we can do at all. Of course, we knew we want to do something to reduce the

maintenance, to improve look and feel of the applications. And now if you start to look at what you can do, then we try to structure it a bit with respect to how much effort it is to apply specific kinds of approaches. At the bottom level, of course, you can say we keep everything as is, then we don't change anything to the current state of the art. On

the other end of the spectrum, that's where we started with is let's say we replace everything. We start a new. If you build new applications, you will usually take a look at web-based stacks nowadays when building front ends. So, you could of course think about replacing everything. But of course, there is something in between as you can imagine that this is really much effort to do a

complete replacement. So, of course, you can say let's replace some of the OS specific implementations. We have seen this problem on Windows, on Mac OS for example, it does not look too outdated. So, we could say well, let's adopt a new Windows API, a new Windows library for the UI like WinUI 3 or on Linux we need to adopt GTK 4 anyway. But when we think about

making one new implementation for one OS, then the question is why do it for a specific OS and why not do it in an OS agnostic way anyway, because nowadays the native implementation is not such a selling point anymore and there are many frameworks out there that would allow you to be independent from the OS for yeah, for basically free because that libraries are doing that. And

some borders that we draw here is in particular on the top that we said that the top most approach is nothing we want to do because that usually is what we call the migration approach because consumers will need to adapt. Applications cannot just use the new implementation as a drop-in replacement, but they will have to adapt their applications. That's why we didn't want to follow this um

approach at the top. And we said of course if we do a new implementation anyway, why not do it in an OS agnostic way if it's feasible. So that's why we took a look at this kind of approach and which also drove us was that we we did a quick prototyping with the existing GTK implementation of SWT which is for for the for the Linux um usage

of Eclipse SWT and there is support of the GTK library for Windows and we tried to use it and it just took a few hours to get Eclipse applications, the Eclipse SDK running on Windows using the GTK port. And what was even more interesting is that I just tried it with the provision product I've shown you in the beginning and as I said it's a Windows only

product so I expected it to have severe problems to be run with GTK, but actually it was only two places in the code I had to change and then it worked and uh started with the GTK implementation. And that was very impressive to see because it was a very good initial indicator that it could be possible to get something OS independent as one single implementation of SWT.

So we thought it could be feasible to do it if it's even possible with GTK, maybe with even more sophisticated frameworks out we started the project with exactly this direction. Then we defined the goals, which directly came from the pain points that we've seen. We wanted to have a more modern or at least controllable look and feel. Modern is always subjective, of course. Uh we wanted to

reduce maintenance, and we wanted to improve the customizability of this. And we also defined some constraints. In particular, the first one was very important for us, as I've said before already. We wanted to keep the effort for the adopters low. So, we wouldn't didn't want to have the applications adapt to new APIs, but we wanted to keep the APIs the same, so that effort is low. Of

course, the technology must be cheap, it must be maintainable, and so on. You need to fit to the skill set, so we have usually Java developers in our community, so skill set was important. But the primary constraint that we had was this effort for adopting, so keeping the API changes minimal. That was the starting point of initiative 31, and we then in the beginning or in May

2024 started with a prototyping phase initiated by the Eclipse IDE working group. So, the phases for this project that we imagined if we would do it to the end. So, the the goal of initiative 31 was never to have a production-ready state, but first to do an evaluation if it would be possible to do such an implementation. These are the phases that you could have if you

want to go the path until a production-ready implementation um in an OS-agnostic way. So, we're starting, of course, with the existing three Then we wanted to start some prototyping with specific technologies that we had selected, then come to some conclusion which of them is most promising, and really implement a production-ready implementation with that technology. And then, if it's a production-ready, put it to the three existing ones,

so that you can really use it as an alternative for productive use. And in case no one is interested in the native implementations anymore and no one would maintain them anymore, they eventually may be dropped. So, one misunderstanding was all the time that this was the actual plan to get rid of all of them. Of course, that would be great if the new implementation would be better

than all the others and no one needs them, you could remove them for reducing the maintenance, but of course, if there are companies or people using the native implementations and would be interested in them, you could still keep maintaining them. Uh that was always a concern that we want to remove native Then, we started into an initial evaluation of technologies because there are many, many technologies out

there. We made a systematic evaluation of what what exists. Uh we took a look at more than far more than 20 technologies and um yeah, discussed them regarding specific criteria. Some of the most important were the active maintenance, wide adoption because Eclipse products are usually very long-living. You know, we're talking about 10 plus years for many products. So, you really want to have a technology that will

be long-living and actively maintained. Uh that was, for example, the reason why we also dropped technologies like JavaFX and Flutter, which are kind of interesting, but which did not fulfill these criteria. The technologies that we started with are obviously GTK because we had this prototype already. There is this existing implementation with the macOS and Windows ports. There is great theming support integrated into GTK. It's definitely widely

adopted in the Linux ecosystem. So, that was an interesting candidate. The second one was Swing, also because there was an existing implementation, a rudimentary one. It is pure Java. So, from a skill set perspective, it's great, and it ships with the JDK, so it's easy to deploy. So, some great benefits as well. And the third technology we investigated was Skia. So, Skia is just a rendering engine

or the widget framework, but a very modern one, of widespread one used in many products like Chrome, Firefox, LibreOffice, and many other applications. You have great GPU rendering support. You also have web assembly support, so we might have had a pass to the web. And we wanted to combine it with the VCL library from LibreOffice, so the widget library used in LibreOffice, which is also using Skia.

So we thought there is something existing which we might adopt for the Eclipse ecosystem. those three technologies was what we started with in the prototyping phase, so we really implemented stuff and tried it out uh throughout 2024. Uh we presented the results of that at last OCX and did an interested party call asking people if they're interested to uh yeah to invest into these technologies, which of

them they find most interesting. And as you can see, we finally selected Skia at the end of 2024 and started into a further demonstrator phase to really see how far we can come, mitigate risks that we see, and so on. So selecting Skia means we dropped GTK. Uh GTK was dropped because of So one thing was performance issues, but the most important one was that GTK 4

adoption became so important that the GTK 4 implementation was then done by the people um doing the prototyping in the initiative before. And for the rest of the team, the interest in the Skia technology was higher, which is simply why they moved on with that. Something similar applies to the Swing prototype. So one aspect was missing browser integration, which we could have solved. Um but there was

a low community interest, so we had a small hackathon on that technology, but the people um involved in the project were not so interested in investing into that technology, which is why we focused on Skia starting from the end of 2024. But actually, the selection of Skia together with the um uh LibreOffice widgets is something we dropped as well even earlier already, because it would have had

some some of the same drawbacks that we currently have with SWT with its native adoptions. The LibreOffice developers themselves advise against that. Um so we dropped that idea and we just wanted to prototype first if it's possible to go with a custom rendered or custom implemented widgets. We first thought it could be very high effort and actually it is quite some effort, but it was interesting to

see how fast we made progress and how much benefits you get when following this approach of having your own widget library on top of a performance rendering engine. So one is obviously that you're pure Java, so productivity is very high. We saw that when moving from the VCL adoption, a C++ library, with interprocess communication and so on, then moving over to using a custom implemented widget was

really a performance and productivity gain in the team. Of course, you get great flexibility because you do everything on your own. You have everything in your hands. You can exchange renderers, achieve full customizability however you want. Then the dependencies are very lean. Uh we will see that in a minute on a separate slide. Um platform independence is automatically given by for what Skia is implemented on, which

are many, many platforms including the major operating systems and web assembly. And you can do an incremental replacement, replacing one existing widget after another with custom one. So that's also great from a project organization perspective. And these initial results that we had led to very, yeah, strong enthusiasm in the group because we had so fast progress and wanted to move on with So as I said, we

have lean dependencies here. Um which is because you basically only have to do a GC implementation when adopting Skia or any other graphics library. So if we take a look at the technology stack that you achieve with such an implementation is that on top of course you have your applications, Eclipse applications or anything else using the SWT API. Then of course all the widgets implement the existing

API. But for their implementations they right now use many, many aspects of the operating systems, of their APIs, of course. There will probably be some minor remnants, so some some things that you use from the OS APIs, but most of the widget implementations will just use the GC. So, this is the the instance for drawing primitives, drawing rectangles, text, and so on. That's what the rendering of

the widgets is using for for rendering their appearance. And the GC implementation then has to adopt some graphics library like Skia. And obviously, the great thing here is if at some point in time you have to decide that Skia is not the proper fit anymore, you want to use a different rendering library, maybe the native ones or something else, you just have to re-implement this GC interface

for the new library, but your widgets, your custom widgets can still stay the same because they only depend on this GC. This is not fully true, to be honest, because there are some specifics like the text layout in SWT is very complex and directly accesses the graphics library, but to a to large degree, this is true that you get this very lean interface of the GC and

does a great exchangeability and a separation of the rendering part and the implementation of the widgets look and feel. So, from an architectural perspective, that's definitely a benefit of this separation approach, graphics engine and widget implementation separated. at the end of this uh prototyping phase, we decided to move on uh to a demonstrator phase, which was the first half of 2025 then, with the goal to prove

that it's feasible to achieve a final implementation, a full production ready implementation. There were some things we hadn't evaluated before, some specific uh things like event handling stuff and performance problems and so on, which we wanted to know if we could reach a state that is productively usable at the end. So, that was the goal of moving forward with this demonstrator phase. For that, more people joined

us after this interested party call that we did at the end of 2024. Then, in this phase, on average, we had like three people people in in full time working on this sinking in weekly meetings and sharing everything documents code and so on at GitHub which is of course still available. One challenge was that in the interested party call actually many people joined and signaled their interest

to do active contributions really making active code contributions but only few did. I mean that's something we know from open source of course in general and applied here as well. So the sustained contributions really came from a very small team very small core team constantly working on this but as you can see in the numbers here with this three full-time equivalents not that many people doing the

actual work. What we did in this demonstrator phase so the goals were two-fold so one was doing incremental progress so we really wanted to move forward towards the final implementation replacing one widget after another implementing one functionality after another and always keeping the SDK launchable so that was always the goal to with every step still make it possible to see how the SDK behaves after the next

change. On the other side we wanted to mitigate risks so see where potential conceptual or technical blockers could be and mitigate them and for that we sometimes had to do targeted prototypes because there was nothing we could do incrementally but really had to do separate prototyping to find out if something is possible or not. So for this we had then two parallel development streams one as said

was this incremental replacement where we had a really agile transition with the coexistence of native and custom widgets so we replaced one widget after another the native one with the custom implementation and we always kept the SDK working so it was always or almost always possible to still start the Eclipse SDK and see how everything works and appears which led to a great motivation of course because

you really see continuous progress you see that it works and you can really evaluate that everything works all the time and you will not be surprised at the end when doing some kind of big bang approach for that. At the risk mitigation stream, we did specific prototypes for specific topics like for event handling, we did a complete replacement of the event handling implementation because that was still

done by the operating system in our incremental approach. We did some experiments with browser integration to see if that works to have a browser or even other native windows integrated like you can do now in SWT. And also performance aspects were evaluated. For example, we currently still render every widget in their own canvas and then merge everything together, but rendering everything in one single canvas, one large

canvas would have much better performance and that's something we evaluated separately in a specific Then the overall results of what we did here in this phase was that actually it's possible. So, what we achieved is that every widget is implemented in a rudimentary way, in a preliminary way. Um yeah, based on Skia or at least the GC interface. We saw that basically all of the SWT API

is implementable and all the risks that we have seen in the beginning, all major risks were mitigated. So, in terms of performance, we did some evaluations which gave very good results and have shown the great performance that you get with Skia. And also that browser integration, for example, is possible. So, with the overall result here was that we said, "Okay, this is possible. We could do it.

We just have to invest the necessary resources and then we will finally come to production ready implementation of SWT based on Skia." So, to give you some impression of what we did for this incremental approach, incremental replacing the widgets, it looked roughly sketched like this. We all the the left side, as you can see, still had a native window. So, everything was terms of the window presented

to the user. Then we still all the time had some natively implemented widgets. Like for some time we had the text widget still natively implemented and shown inside the window. And one of the first widgets that we replaced was the button. So we made a custom implementation of the button which then used the GC interface to render its its contents. Yeah, the the button boundaries and the

text inside it. And then you could switch between using the original GC, the native GC, and on the other side the Skia GC. And what then happened is if you chose to use the Skia GC is that you render with Skia. But since everything, the whole window is finally done by the OS, you still have to move the final result of the rendering over to a native

GC to then present it to the user. So this is an indirection that you see there something that we had to do temporarily during this transition phase until you finally replace the native window with a Skia window. So then that part would be removed. Which is also a big performance bottleneck that we had all the time because copying over all the buffers all the time, also copying

images that you want to draw inside images from native representations to Skia back and forth is really a performance bottleneck. But all of that is just for this incremental process to really see if everything is working and that you can completely get rid of at the end when you move everything over to a Skia based implementation. But this allowed us to switch all the time between the

two implementations just using native GC or using Skia GC and evaluate the two against each other. So this was a very beneficial approach of doing this incremental replacement. So as a summary of the achievements that we then had in this phase is that we had a complete implementation of all widgets as I said, so not complete in the sense that every widget was completely done, but every

for every widget we had a preliminary implementation of them. Even for the complex ones like the style text with the text layout we had an implementation that works as you will see in a minute. We have seen that we can implement the GC with Skia, so we implemented those parts that we needed for the widgets, which worked completely fine and was just a matter of effort to

implement everything in the GC interface with We also had some exchangeable renderers implemented to see that we can really reach this customizability of the rendering appearance. Uh we did some prototyping for event handling to see that this works. And what we also had all the time is OS independence, so we had implement implementations tested for all the operating systems. Of course, we didn't check all the time

with every operating system, but we uh really tried to once in a while test on every operating system and adapt that it keeps working. And as I said, also the performance was evaluated in specific prototypes all the time. And now, after having you told all of that, I would like to give you a quick demo of what we have reached in the end. So, this is the

final state that is currently in the repository on GitHub that you can still check out. So, this is just a a workspace. Uh it's the state of June last year, so the Eclipse state of June last year because that was the final state that we reached with the prototype. I've just imported uh the Git projects here, so the SWT implementation using Skia. Um and the first thing

I can show you is this control example that we have in SWT. So, the control example is for testing all the functionalities of all the widgets or all the controls that exist. Now, it's on the wrong monitor. Here we go. So. This is uh yeah, as I said, for just trying out the different um properties that you can set on different widgets. This is, for example, the

first tab for the button where you can see different kinds of buttons, how they look like, and can check the different properties. And everything that you see here is now rendered with uh Skia. You can see that, of course, these uh boxes showing the groups in your UI look not so nice as they do in the uh native implementation. This is a matter of styling that is

not properly applied right now, but rendered with Skia and you can do that basically for um yeah, for every widget that we have. Uh so, all what you see here is custom implemented, fully custom rendered using the Skia engine underneath. And as I said, what we did is all the time ensure that the Eclipse SDK keeps working. So, I will just launch an IDE uh with the

Skia implementation. So, that that we could see that everything is really working also in an integrated way, not only the widgets on their own in an isolated way, but really working together. And here we go. This is how it looks like. This looks probably quite familiar to those of you using Windows. Uh so, you can see uh some differences in the table down here for example, which

looks a bit different in terms of the the borders and so on. And you can see that there is a grayish background in the tool items and so on, which you have to improve in terms of styling. But all of this basically all of this is rendered with Skia as we will see in a minute. Also, if you for example open some some dialogues, you will see

this um weird behavior of the backgrounds. That's something I had I'm not sure what that is. We didn't have that when developing back then, but sometimes it doesn't show everything in the This is how it should look like. So, you see these uh gray backgrounds, which are not properly fitting right now. You have to style that properly, but in general you see the text widgets, labels, drop

downs, and so on. Everything done in a custom way and uh yeah, properly properly working. Also, what you see here is uh code. So, using the style text widget and this is also fully rendered with Skia. It looks quite familiar, I would say, basically like the native implementation. You see a difference probably when selecting stuff because in the native implementation the whole lines are are marked. Here

it's different so that is an indicator that this is not done with the native implementation but you actually don't see that much a difference. Of course not everything is perfectly fine as I said it's a preliminary implementation but the style text with the text layout is really a difficult widget and you can see here that it's working quite well. One thing I would like to do in

the end is to really demonstrate you that all this is done by Skia. I've added a flag here to color the background of all widgets that are rendered by Skia so that you really get an impression of which parts of the UI that you have seen are now actually rendered with Skia and not with the native implementation because as I said the whole window itself is still

done by the operating system also the composite structure is but you see it's not nice but you see that everything is that is colored in blue here is done by the Skia rendering engine done in a custom way so implemented by the colleagues in the project to do a custom rendering of all that stuff. I think that's quite impressive to see how far we've come there that

all these parts are at least preliminarily working in a way that you can really use it looking not perfectly nice but so that you can customize everything it's all implemented in Java code and you can yeah just simply improve the appearance of all these controls. All right. So those are just the screenshots of what I've just shown you which worked fine so we can just skip beyond

that so that's the final state that we reached in the demonstrator. Now the question is what's next when we want to go to a production ready state. So what would need to be done is first of all of course finalization of the widgets. They are preliminary implemented but all the functionality that is shared between the operating systems that you need when you want to use it in

production would have to be implemented. The GC is only implemented to that degree that we need it for the widgets, so the rest needs to be done unless it was already done by Dennis now for the ski implementation that we currently implement in SWT. The event handling still needs to be done and some performance stuff as I mentioned. And the estimate that we have done in the

project to achieve this state, this production ready state is around 20 person years or at least 20 person years and we always talk about a time frame of 2 years. So that it's still motivating for the people involved that it doesn't take too long also in terms of risk management for the companies investing into this. So that would mean that you need 10 people working for 2

years on this project. We've seen in the beginning we had three people in the project, so the gap was quite large and that's actually the reason why we didn't proceed to a to a production ready state of that project because it was clear that we wouldn't reach that state in a in a proper time frame. we didn't stop with just having these insights and knowing that it

would be possible if we would invest the resources, but we have some very concrete topics as follow-ups that we want to yeah, bring upstream to the actual SWT implementation. Two things are GTK 4 support and the ski based GC will will I talk about in a minute and the third one are the custom widgets that we've implemented. Of course, all these custom widgets exist, so there are

implementations. So we have some custom implementations already in SWT like for tab folders and we have many more now done in this project which we could upstream to SWT if we're interested. Some of them even surpass to a certain degree their native counterparts in SWT. So if there is interest in yeah, in replacing or providing alternatives for the existing widgets, this would be an option. I know

that there was some discussion when we ended the initiative 31 about doing that from from some people. I I see anything happen since then. I'm not so interested in that part, but if you are, reach out to me and I can give you the context so that you could maybe upstream custom widgets if you're For the GTK4 support, that's a very important topic right now because GTK3,

the current library that is adopted in SWT, is kind of end of life in the sense that it's not shipped by many major Linux distributions anymore by default. So, SWT needs to adopt GTK4 anyway, and initiative 34 31 was to a certain degree a a driver for this. So, some companies that invested into the implementation in initiative 31 then moved over to doing the GTK4 implementation for

SWT, and there is really some significant work being done in the recent month. This is just a screenshot from last week or so, so there are still some some issues, of course, some also major issues, but there is really significant progress going on so that we will reach an GTK4 based implementation for SWT. So, that's one great outcome. The other one is this Skia based GC. This

is nothing new for those who have heard Dennis talk yesterday. This is about providing an alternative GC implementation for SWT using the Skia library. If it's important for you to have pixel perfect and high performance rendering, so one important or example use case are diagrams, GF diagrams for example, which we are also using in our product. On Windows, performance is a real issue there because the rendering

performance of the native GC is not that good. And also, if you're using different operating systems, the rendering results are slightly different on all of them. So, if you need pixel perfect rendering, having an independent OS agnostic library is also beneficial there. And we're currently upstreaming that, so there are some pull requests existing for integrating that into upstream SWT. This is a screenshot just of one of

the examples that Dennis has shown And it could also be a foundation for future work. So, if we move on with what we have evaluated in the initiative, doing custom widgets, then we would have the Skia implementation in SWT already when this is upstreamed. So, I think this is a really great result if we get this in SWT as one of the outcomes. And one third topic

I would like to mention, which is not directly related to the initiative, but which covers the broader scope of improving the look and feel of Eclipse and SWT, where we've put quite much effort into the last years anyway. So, we did the stuff regarding SVG support, high DPI support, better theming, or default themes. And one thing that is currently being done is implementing icon theming because currently

the icons are, yeah, also looking a bit outdated. They're gradient-based icons from 20 years ago and so on. And it's not that easy to exchange those icons because they need to fit to all the extensions. So, it's about the theming capability so that you're able to, yeah, define a different theme and apply a different theme to your icons. Currently, a new theme of icons is being developed.

So, there is a bunch of icons already existing. These are the screenshots from that work being done. What is missing is a mechanism to do the replacement. That's something that needs to be done, but I'm very looking forward to that we maybe this year or next year get an icon theming mechanism and a new set of icons to have a refreshed UI of Eclipse in that way.

So, before coming to an end, I would like to talk about some takeaways from this project beyond the direct content-wise results and some lessons learned from this kind of project. First of all, because before coming to concrete takeaways and lessons learned, one thing I often found in discussions, what was very interesting, is the expectations coming with the replacement of a widget framework, or rather the over-expectations coming

from that. Because some people really expected that if you just replace the UI library, the graphics and widget framework, that you get a fully refreshed user experience. Yeah, completely out of the box changed look and feel everything looking modern without doing anything, improve responsiveness and workflows. So, some people really have expectations that you will never fulfill with just a replacement of a of a widget framework. One

example that I've given in a different talk is yeah, indicated by these two progress bars. So, let's say once when you type in your application and get such a progress bar telling you we have to wait for 30 minutes now. Of course, you can improve the UI and say let's make a nicer background, nicer progress bar, maybe some further abolishment, but you would agree that the problem

here is not the the look and feel of the progress, but that this is not done asynchronously or in some other way. So, this is a real user experience issue and not about the the widgets being used or the look and feel. So, we know we've seen in the talk what it actually enables this replacement is maintenance effort reducement and enhanced look and feel and customizability. And

one thing I always find important to know is leverage the existing capabilities. There so much we can do with Eclipse right now using the Z mean capabilities, improving current SWT. Yeah, we implemented high DPI or better high DPI support throughout the last years, SVG support and so on. So, you can do really much with what we have already. So, I think it's really important to think about

what you actually need if you feel some some pain points and not directly replace the whole library. I've given a full presentation on this kind of topic. If you're interested, you can also reach out to But now coming to the to the lessons learned or takeaways in general. So, from a technical perspective, what we've learned here is that such a large scale API compatible replacement in SWT

is possible. That's what we have seen with the demonstrator that we have developed. And this is possible in an OS agnostic way. That's also what we've seen in this demonstrator. We can achieve a production ready state based on Skia. The remaining work is just a matter of effort, not of issues. Then this incremental approach, which I have uh talked about, is in my opinion invaluable. So, we

had quite some discussions about rather doing a big bang approach. Some people in the team wanted to start from scratch because it's faster, of course. First, it's faster, but it's really dangerous because you don't know whether you reach the goal or not. And in my opinion, it was really great that we now have this where we can really uh feel how it uh how it looks like

and how it behaves in a complete Eclipse SDK because of this incremental approach. And one thing that is not so surprising, we all know that you have to match your skill set uh of the people involved to to what you're doing, but we've greatly seen it in this project when moving from the C++ LibreOffice widgets to our custom implementation in terms of the productivity gain that we

had. So, that was really great to see this live uh how the the skill set matching the um the technology affects the productivity. Then on the more organizational side, first thing is that for this kind of project, I would say dedicated project and technically it is very essential. I tried to fill this role to a certain degree, but actually I didn't have too much time to do

that. And in my opinion, it would have been very beneficial to have a person doing like half at least half time or maybe more, keeping the strings together, keeping people motivated, having the road map um in the head and so on to really drive this project in a in a structured way. One thing that worked quite well is committing to decisions. So, what I found really difficult

is that we have many volunteers, many interests, of course, and you don't want to piss anyone off because he or she has a different opinion because they're all volunteers there, but still you have to commit to some decisions. Yeah, you need to find agreements because otherwise everyone will be pulling in different directions. So, this worked quite well, in my opinion, but it's definitely important to include everyone

into the Then the commitment culture is of course always a thing in open source. Um we've seen here that the final commitment to invest more resources for achieving a production-ready state was missing. That was why we didn't come to a production-ready state. So, we really need to have a have a strong commitment for for doing the work so that you can move on in a proper way.

And as a final thing, uh team building. Something that we actually didn't do in in my opinion. So, we were spread across countries, across cultures. We didn't do any team building. We just joined the meetings for discussing contents. And in my opinion, it is very beneficial even for such a project to do better team building to bring together the people to have a yeah, a good working

atmosphere. Something I would definitely take away for next time of such a So, to conclude on this, uh what I've shown you is that we've successfully demonstrated that this is possible, that it's only about the resources, not about risks, achieving such an implementation. We've also seen that this incremental approach is the right thing you can do. Of course, we don't have the resources to finalize it, but

everything is still there. We have the results documented at GitHub. Um I really want to thank all the contributors. It was such a great experience. Uh I don't want to name anyone in specific because there were so many people involved in different ways, and it's uh easy to forget someone. But it was a really great work from all of the people involved. And to move on to

the next steps, I can only invite you to the uh both session this evening and the area of the Eclipse platform named Eclipse platform and IDE in the age of AI. So, looking forward to meeting many of you this evening. And yeah, thank you for your interest in this topic. >> [applause] >> Are there any questions? >> Thank you for the very nice presentation. It was a

great overview of the history of the initiative 31 and a bit sad outcome, but sometimes honesty is sad. So that is important. I want to zoom in on the idea of re-implementing all the widgets with custom widgets. So in operating systems stuff like high contrast themes and accessibility topics. And so there's a lot of effort attributed to custom widgets. Would you still say a Skia-based SWT would

in in a total cost of ownership be beneficial compared to the native OS for each platform? Of course, it's only an estimate I can make on that. So I would definitely say yes in the comparison. I mean, you're totally right that things like accessibility and other things like high contrast themes that you've mentioned are a topic that you have to address on your to address on your

own. Actually, the current accessibility implementation is not so well maintained in itself. My expectation is that the the maintenance of these three implementations that we have right now is so much effort that it will still be better to have one single implementation that does not degrade that much automatically because you have to adapt to the OS all the time even though you have to do these additional

things on your own doing accessibility and other because you of course have to do it once. But once you have invested the initial effort, the maintenance effort will be lower. So of course, it's a matter of the initial effort that you have to invest that we have seen, but the maintenance burden would become lower once you have reached a state that works out. Of course, an estimate

I can't fund that with measure match. Thanks. Welcome. Yeah, first of all, I would like to congratulate congratulate the team and and and you for the quality of of the work and the presentation. And I have a very naive question and maybe more for the both. It's Do you think that AI could change AI coding assistant could change this estimation of 20 person years? A very good

question. I Actually, I can't answer that. So, when we did this project, agentic AI was not that common yet and was not that far yet. Maybe doing it now would be different. I remember that Martin asked me like 2 years ago or so at some conference when we started this project, "Hey, can't you just give it to the AI and tell it to implement reimplemented with Yeah,

so he was really early with exactly this idea. Um yeah, maybe we can could reduce the effort that it requires. But I have not tried yet. I would not make any estimate how well agentic AI is in doing this kind of work. So, my experience is that agentic AI is really strong with the native implementation. So, it it's really helpful for the maintenance because the all the

native APIs are trained very well in the in the agents. So, that works really good. I'm not sure how well that works when adopting Skia right now for in particular because much of the work that is about the integrated details, right? About the last uh 10 20%. And that's always the part where AI may not be that strong where you have to do much at least right

now as the as the human developer. So, I'm not sure how helpful it would be, but I'm pretty sure it would definitely reduce the effort that it requires and you can improve Yeah, thanks for the talk. A very interesting and challenging project. Um yeah, what um what thoughts um oh how did you investigate to choose according to how long it will survive? Mhm. Yeah, as I said,

in the beginning we took a look at all the widget libraries, all the graphics libraries out there, and yeah, made an estimate how how long they may live or how high the risk is that they will not outlive the applications that will depend on it. Um we came actually we came to Skia when starting with this top-level approach I've shown you, doing a complete replacement with a

web-based stacks, for example. And when we said, "Oh, that that's not the right thing to do because it's a migration path. You have to adopt your applications uh adapt your applications." We thought, "Okay, but how are browsers doing it? So, what do they do underneath to render their stuff?" And that's where how we came to Skia at all. I didn't hear about Skia before, to be honest.

But we found that Skia as a rendering engine is used underneath and used by many, many products. So, it's um developed by Google, as far as I know. Uh used by so many products that we said, "Okay, it's such a well-founded basis that the risk is really low that this will not be developed further." And as I said, the exchangeability with this architectural separation of rendering engine

and the the widget implementation makes it quite independent from the engine at all. And yeah, regarding all the other widget frameworks, it was more a matter of uh estimating yeah, whether they will outlive the products or not. And as I said, for some examples like uh JavaFX and Flutter, we were not that sure if you should rely on them. OpenGL uh not OpenGL um uh QT, uh

for example, is something that does not fit that well from license perspective and so we had criteria for all the technologies we took a look at why we didn't consider them further. There there are some reports available here at GitHub where you can also take a look at the different technologies to see what we thought about them and yeah, how we came to these three technologies in

the end. Thank you. All right, then I think we should probably move to this reception. I will of course be there and will be there tomorrow. So if you have questions, just come to me and thank you again.