FOSDEM 2015 Desktops DevRoom Call for Talks

by ⋅ Leave a Comment

FOSDEM is one of the largest gatherings of Free Software contributors in the world and happens each February in Brussels (Belgium). One of the tracks will be the Desktops DevRoom (formerly known as “CrossDesktop DevRoom”), which will host Desktop-related talks.

We are now inviting proposals for talks about Free/Libre/Open-source Software on the topics of Desktop development, Desktop applications and interoperability amongst Desktop Environments. This is a unique opportunity to show novel ideas and developments to a wide technical audience.

Topics accepted include, but are not limited to: Enlightenment, Gnome, KDE, Unity, XFCE, LXQt, Windows, Mac OS X, software development for the desktop, general desktop matters, applications that enhance desktops and web (when related to desktop).

Talks can be very specific, such as the advantages/disadvantages of development with Qt on Wayland over X11/Mir; or as general as predictions for the fusion of Desktop and web in 5 years time. Topics that are of interest to the users and developers of all desktop environments are especially welcome. The FOSDEM 2014 schedule might give you some inspiration.

Please include the following information when submitting a proposal:

  • Your name
  • The title of your talk (please be descriptive, as titles will be listed with around 250 from other projects)
  • Short abstract of one or two paragraphs
  • Short bio (with photo)
  • Requested time: from 15 to 45 minutes. Normal duration is 30 minutes. Longer duration requests must be properly justified. You may be assigned LESS time than you request.

The deadline for submissions is December 7th 2014. FOSDEM will be held on the weekend of January 31st-February 1st 2015 and the Desktops DevRoom will take place on Sunday, February 1st 2015. Please use the following website to submit your proposals: https://penta.fosdem.org/submission/FOSDEM15 (you do not need to create a new Pentabarf account if you already have one from past years).

You can also join the devroom’s mailing list, which is the official communication channel for the DevRoom: desktops-devroom@lists.fosdem.org (subscription page for the mailing list)

– The Desktops DevRoom 2015 Organization Team

On HTML5 and native

by ⋅ 1 Comment

A few months ago I wrote on my disbelief of HTML5 being the right tool for everything . Some people took that as me saying HTML5 is useless.

That’s obviously not true and it’s certainly not what I think.

It’s my opinion there is room for HTML5 and there is room for native applications and the decision on what to use should not be taken lightly.

Here are a few questions that may help you to make a wise decision.

 

Target user

Is it corporate? Is it consumer?

Corporate devices are usually under control and users may not be able to install software.

Or traffic may be filtered and users cannot browse to your website to use your webapp and getting the authorization will take months, therefore they give up before they have even started using it.

Or they may be on a slow Internet connection and using that HTML5 webapp that took years to develop and add all those nice effects is hardly possible due to megabytes of JavaScript and images needing to be downloaded.

As for consumers, despite having full control of their systems, it’s not roses either: not all consumers know how to install software and/or they may be scared by UAC dialogs (hint: always sign your software with a certificate whose signature chain reaches VeriSign).

 

Target device

Is it a computer? Smartphone? Tablet? Web browser?

If a computer, is it a PC running Windows? Linux? Mac? All of them? Are you trying to reach as many platforms as possible?

How old of a computer are you targeting? Pentium 4? Core 2 Duo? Core i5? How much RAM? Try a fancy website with a lot of HTML5 niftiness on an old computer and you’ll probably be surprised at how slow HTML5 can be, even on modern browsers.

 

Deployment

Deploying native applications in corporate environments is a bit of a nightmare due to different operating system versions, hardware, etc

Deploying native applications in consumer computers is only a problem if you are targeting low-skilled users.

HTML5 is easy to deploy, provided that you can get the user to use a proper version of the browser. This is workable with consumers but often impossible with corporate, so if you go for HTML5 for a corporate application, make sure you support everything from at least down to Internet Explorer 8.

For mobile devices (smartphones and tablets), it doesn’t really matter whether it’s an HTML5 or native application: it has to be installed on the device, the device goes with the user everywhere and when the user moves to another device, re-installing all the applications is a matter of accessing the Apple Store, Android Market or equivalent and say “download it all”.

Read More →

Guidelines on cross-platform porting

by ⋅ 4 Comments

There is a nifty piece of software called zsync, which is kind-of like rsync, except it is totally different.

Rsync

Rsync is mainly useful when you want to synchonize a list of files, or directories, between two servers. It will only download the new files and files which have changed. It will even delete or backup the files which have been removed at the original site. Nice.

For a project I was involved until recently at work we had a slightly different problem: we generate a huge file (an ISO image) which contains about 6 GB of data. This ISO image contains the daily build of our application. It contains only a handful of files. Problem is some of them are generated and GB in size, yet from day to day only maybe 100-150 MB have changed (and it would be even less if it were not because of this “feature” of .NET that never generates identical binaries even if using exactly the same source code)

Rsync was not useful in this case: it would download the whole file, gigabytes! (some of the people downloading the ISO are on a slow link in India)

 

zsync

This is exactly the case zsync targets: zsync will only download the changed parts of the file thanks to the rolling checksum algorithm.

Best of all: no need for an rsync server, opening port TCP 873 (which requires months of arguing with BOFHs in some companies), or anything special: HTTP over port 80 and you are done. Provided that you are not using Internet Information Server, which happens to support only 6 ranges in an HTTP request (hint: configure nginx in reserve proxy mode).

But I’m digressing.

Cool. Great. Awesome. Zsync. The perfect tool for the problem.

 

Hello Windows

Except for this project is for Windows, people work on Windows, they are horrified of anything non-Windows, and zsync is only available for Unix platforms.

Uh oh.

In addition to that, the Cygwin port suffers from many connection error problems on Windows 7 and does not work on a cmd.exe prompt, it wants the Cygwin bourne shell prompt.

So I started to port zsync to Windows natively.

 

Native port howto

The starting point was:

  • C99 code
  • autotools build system
  • No external dependencies (totally self-contained)
  • Heavy use of POSIX and Unix-only features (such as reading from a socket via file descriptors, renaming a file while open, deleting a file while open and replacing it with another file yet still use the same file descriptor, etc)

To avoid breaking too much, and because I wanted to contribute my changes upstream, my intention was to do the port step by step:

  1. Linux/gcc/autotools
  2. Linux/gcc/CMake
  3. Cygwin/gcc/CMake
  4. MSYS/MinGW gcc/CMake
  5. Visual C++/CMake

 

Autotools

Autotools was the first stone in the path.

With some work (calling MSYS from a DOS prompt, etc) it would have been possible to make it generate a Visual C++ Makefile but it would have been painful.

Plus the existing autotools build system did not detect the right configuration on MinGW.

Step 1: replace autotools with CMake. On Linux. This was relatively easy (although time consuming) and did not require any change in the code.

 

Cygwin

The second step was to build zsync on Windows using Cygwin (which provides a POSIX compatibility layer) and CMake.

No code changes were required here either, only a few small adjustments to the CMake build system. I tested on Linux again, it worked fine.

At this point, I had only made a pyrrhic progress: zsync was still Unix only, but with a cross-platform build system.

 

MinGW

My next step was a serious one: port zsync to use MinGW, which generates a native Windows application with gcc.

That means using Winsock where required.

5And hitting Microsoft’s understanding of “POSIX-compliant”: the standard Windows POSIX C functions do not allow to treat sockets as files, rename open files, temporary files are created in C:\ (which fails on Windows Vista and newer), etc. And that’s when the functions do exist. In many cases (mkstemp, pread, gmtime_r…) those functions were outright inexistent and I needed to provide an implementation.

Plus adapting the build system. Fortunately, I was still using gcc and Qt Creator provides great support for MinGW and gdb on Windows, and decent support for CMake.

Some other “surprises” were large file support, a stupid “bug” and the difficulties of emulating all the file locking features of Unix on Windows.

Regarding LFS, I took the easy path: instead of using 64-bit Windows API directly, I used the mingw-w64 flavor of gcc on Windows, which implements 64-bit off_t on 32-bit platforms transparently via _FILE_OFFSET_BITS.

 

Visual C++ misery

Porting to Visual C++ was the last step.

This was not strictly required. After all, all I had been asked for as a native version, not a native version that used Visual C++.

Yet I decided to give VC++2010 a try.

The main problem was lack of C99 support (though you can partially workaround that by compiling as C++) and importing symbols due to lack of symbol exports in the shared library (attributes for symbol visibility were introduced in gcc4.0, but many libraries do not use them because gcc does its “magic”, especially MinGW, which will “guess” the symbols).

Porting to Visual C++ 2010 required either to give up some C99 features in use (e. g. moving variable declarations to the beginning of the functions) or adding a lot of C++-specific workarounds (extern “C”).

I was a bit worried upstream would not accept this code because it didn’t really provide any benefit for the application (for the developer, use of a great IDE and very powerful debugger), therefore I didn’t finish the Visual C++ port. Maybe some day if Microsoft decides to finally provide C99.

The result (so far) is available in the zsync-windows space in Assembla.

 

A wish a day 16: libdbusfat

by ⋅ 11 Comments

D-BUS (Desktop Bus) is a simple inter-process communication (IPC) open-source system for software applications to communicate with one another. It replaced DCOP in KDE4 and has also been adopted by Gnome, XFCE and other desktops. It’s, in fact, the main interoperability mechanism in the “Linux desktop” world thanks to the freedesktop.org standards.

The architecture of D-Bus is pretty simple: there is a dbus-daemon server process which runs locally and acts as a “messaging broker” and applications exchange messages through the dbus-daemon.

But of course you already new that because you are supersmart developers and/or users.

D-Bus on Windows

What you may not know is how much damage is D-Bus making to open source software on Windows.

A few years ago I tried to introduce kdelibs for a large cross-platform project but I got it rejected, despite some obvious advantages, mainly due to D-Bus.

Performance and reliability back then was horrible. It works much better these days but it still scares Windows users. In fact, you may also replace “it scares Windows users” with “it scares IT departments in the enterprise world*”.

The reason?

A dozen processes randomly started, IPC with no security at all, makes difficult to upgrade/kill/know when to update applications, and many more. I’m not making this out, this has already happened to me.

* yes, I know our friends from Kolab are doing well, but how many KDE applications on desktop have you seen out of that “isolation bubble”

D-Bus on mobile

One other problem is D-Bus is not available on all platforms (Android, Symbian, iOS, etc), which makes porting KDE applications to those platforms difficult.

Sure, Android uses D-Bus internally, but that’s an implementation detail and we don’t have access to it). That means we still need a solution for platforms where you cannot run or access dbus-daemon.

Do we need a daemon?

A few months ago I was wondering: do we really need this dbus-daemon process at all?

What we have now looks like this:

As you can see, D-Bus is a local IPC mechanism, i. e. it does not allow applications to communicate over the network (although technically, it would not be difficult to implement). And every operating system these days has its own IPC mechanism. Why create a new one with a new daemon? Can’t we use an existing one?

I quickly got my first answer: D-Bus was created to expose a common API (and message and data format, i. e. a common “wire protocol”) to applications, so that it’s easy to exchange information.

As for the second answer, reusing an existing one, it’s obvious we cannot: KDE applications run on a variety of operating systems, every one of them has a different “native” IPC mechanism. Unices (Linux, BSD, etc) may be quite similar, but Windows, Symbian, etc are definitely very different.

No, we don’t!

So I though let’s use some technospeak buzzword and make HR people happy! The façade pattern!

Let’s implement a libdbusfat which offers the libdbus API on one side but talks to a native IPC service on the other side. That way we could get rid of the dbus-daemon process and use the platform IPC facilities. For each platform, a different “native IPC side” would be implemented: on Windows it could be COM, on Android something else, etc

Pros

The advantage of libdbusfat would be applications would not need any change and they would still be able to use DBus, which at the moment is important for cross-desktop interoperability.

On Unix platforms, applications would link to libdbus and talk to dbus-daemon.

On Windows, Android, etc, applications would link to libdbusfat and talk to the native IPC system.

By the magic of this façade pattern, we could compile, for instance, QtDBUS so that it works exactly like it does currently but it does not require dbus-daemon on Windows. Or Symbian. Or Android.

QtMobility?

QtMobility implements a Publish/Subscribe API with a D-Bus backend but it serves a completely different purpose: it’s not available glib/gtk/EFL/etc and it’s implemented in terms of QtDBUS (which in turn uses dbus-daemon for D-Bus services on every platform).

It’s, in fact, a perfect candidate to become a user of libdbusfat.

Cons

A lot of work.

You need to cut dbus-daemon in half, establish a clear API which can be implemented in terms of each platform’s IPC, data conversion, performance, etc. Very interesting work if you’ve got the time to do it, I must say. Perfect for a Google Summer of Code, if you already know D-Bus and IPC on a couple of different-enough two platforms (Linux and Windows, or Linux and Android, or Linux and iOS, etc).

Summary

TL;DR: The idea is to be able to compile applications that require DBus without needing to change the application. This may or may not be true on Android depending on the API, but it is true for Windows.

Are you brave enough to develop libdbusfat it in a Qt or KDE GSoC?

HTML5 for everything?

by ⋅ 37 Comments

Apparently HTML5 applications are the best thing after sliced bread.

HTML5 is the first platform any mobile vendor supports: iPhone, Android, Windows Phone, BlackBerry, Symbian. All of them.

Windows 8 is said to promote HTML5 as the preferred application development solution.

I used to look kindly at that. But about a month ago I started to get worried: is HTML5 good for everything?

Long-lived applications

In military, industrial, warehouse management, medical, etc is not rare that bespoke applications are developed and stay in use for many years (and I really mean many: 10, 20 or even more!) with barely an update. It’s not rare that those applications only receive very small updates once very 5 years. Those applications, not Angry Birds, are what keeps the world running: troops know what supplies they can count on, iPhones are manufactured, FedEx is able to deliver your package and your doctor is able to check your health.

But now that everybody seems to be moving to HTML5 webapps, what happens when my warehouse management application is a webapp and the additions in the newest browsers make the webapp no longer work?

Are vain upgrades the future?

Say my webapp is released in 2014 and it works fine with Firefox 14.0 and Chrome 26.0, the newest browsers when I release the application in 2014. Fast-forward to 2020 and Firefox 14.0 and Chrome 26.0 do not even install on Windows 10 computer! What’s the solution?

Should the customer pay for a huge update and redesign to make it work with Firefox 27.1 and Chrome 41.0 in 2020?

A virtual machine with Windows 8 and Firefox 14.0? A portable Mozilla Firefox 14.0 on Windows 10 in 2020 to be able to use that line-of-business application that only requires a small update once or twice every 5 years? How are the virtual machine and/or Portable Firefox 14.0 different from or better than a fat client? What’s the advantage? I’d say none!

Native applications usually do not have that kind of problems because APIs are much more stable. You can still run Win16 applications on Windows 7!

You don’t believe me? We may soon be developing for 76 browsers!

While HTML5 may be fine for applications which are updated very often, it makes me feel very uneasy to see it used in environments where applications will be rarely updated, such as SCADAs, warehouse management, control system, medical records, etc.

A solution is needed

It looks like that choice of technology is going to make those applications much more expensive in the medium and long term, paying for “adaptations to new browsers” (sorry, I resist to call “update” or “upgrade” to something that adds zero value other than being able to run on a newer browser).

Or maybe it’s about time to define actual “HTML5 profiles”. ACID3 seems to be too weak of a profile: two very different browsers may pass ACID3 yet a webapp would work with one browser and fail with the other due to bugs, missing features/added features, etc.

Something needs to be done.

FOSDEM 2012 – CrossDesktop DevRoom Call for Talks

by ⋅ 4 Comments

FOSDEM is one of the largest gatherings of Free Software contributors in the world and happens each February in Brussels (Belgium). One of the developer rooms will be the CrossDesktop DevRoom, which will host Desktop-related talks.

We are now inviting proposals for talks about Free/Libre/Open-source Software on the topics of Desktop development, Desktop applications and interoperativity amongst Desktop Environments. This is a unique opportunity to show novel ideas and developments to a wide technical audience.

Topics accepted include, but are not limited to: Enlightenment, Gnome, KDE, XFCE, Windows, Mac OS X, general desktop matters, applications that enhance desktops and web (when related to desktop).

Talks can be very specific, such as developing mobile applications with Qt Quick; or as general as predictions for the fusion of Desktop and web in 5 years time. Topics that are of interest to the users and developers of all desktop environments are especially welcome. The FOSDEM 2011 schedule might give you some inspiration.

Please include the following information when submitting a proposal: your name, the title of your talk (please be descriptive, as titles will be listed with around 250 from other projects) and a short abstract of one or two paragraphs.

The deadline for submissions is December 20th 2011. FOSDEM will be held on the weekend of 4-5 February 2012. Please submit your proposals to crossdesktop-devroom@lists.fosdem.org

Also, if you are attending FOSDEM 2012, please add yourself to the KDE community wiki page so that we organize better. We need volunteers for the booth!

 

The most stupid C bug ever

by ⋅ 98 Comments

I have been programming for a number of years already. I have seen others introduce bugs, and I have also introduced (and solved!) many bugs while coding. Off-by-one, buffer-overflow, treating pointers as pointees, different behaviors or the same function (this is specially true for cross-platform applications), race conditions, deadlocks, threading issues. I think I have seen quite a few of the typical issues.

Yet recently I lost a lot of time to what I would call the most stupid C bug in my career so far, and probably ever.

I am porting a Unix-only application which uses tmpfile() to create temporary files:

            else if (code == 200) {     // Downloading whole file
                /* Write new file (plus allow reading once we finish) */
                g = fname ? fopen(fname, "w+") : tmpfile();
            }

For some awkward reason, Microsoft decided their implementation of tmpfile() would create temporary files in C:\, which is totally broken for normal (non-Administrator) users, and even for Administrator users under Windows 7.

In addition to that, the application did not work due to another same-function-diffent-behavior problem.

To make sure I did not forget about the tmpfile() issue, I dutifully added a FIXME in the code:

            else if (code == 200) {     // Downloading whole file
                /* Write new file (plus allow reading once we finish) */
                // FIXME Win32 native version fails here because Microsoft's version of tmpfile() creates the file in C:\
                g = fname ? fopen(fname, "w+") : tmpfile();
            }

Read More →

A wish a day 11: Perl Compatible Regular Expressions in CMake

by ⋅ 6 Comments

CMake is a unified, cross-platform, open-source build system that enables developers to build, test and package software by specifying build parameters in simple, portable text files. It works in a compiler-independent manner and the build process works in conjunction with native build environments, such as Make, Apple‘s Xcode and Microsoft Visual Studio. It also has minimal dependencies, C++ only. CMake is open source software and is developed by Kitware. (taken from Wikipedia)

But you already know that because CMake is the build system we use in KDE 🙂

When I started to use CMake at work to port a large project from Windows to Linux, I needed to write a lot of modules (“finders”). Those modules had to work on Windows and Linux, and sometimes with different versions of some of the third-party dependencies. Parsing header files, Windows registry entries, etc was often required.

If you have ever parsed text, you know you powerful regular expressions are. If you use old software, you know how great Perl Compatible Regular Expressions (PCRE) are because you do not have them available :-).

Read More →

A wish a day 9: QML WPF

by ⋅ 11 Comments

When Stephen Elop announced Nokia was adopting Windows Phone 7 as its main development platform for the future, many of us felt a mix of fear for our jobs, incredulousness (are they committing suicide?), anger for betraying open source, then curiosity. What’s this WP7 about and what’s up in regards to development?

The canonical development platform for WP7 consists of Visual Studio 2010 and managed applications developed in .NET 4 using C# as the programming language and a WPF for the user interface. If you are not into .NET, you may be a bit lost now.

Windows Phone 7 is an embedded operating system by Microsoft. It is the successor to Windows Mobile 6.5 but it is incompatible with it and it is targeted at mobile phones.

Visual Studio is Microsoft’s development environment, including IDE, compiler, debugger, profiler and much more. In my opinion, it is one of the finest applications Microsoft has developed. It is many years ahead of QtCreator, KDevelop, Eclipse or anything else.

.NET is a framework Microsoft started more than a decade ago. It includes libraries, a language independence infrastructure, memory management, localization and many more features. Applications can be compiled as native code (for x86 or x64), or as managed code (bytecode). .NET also includes a bytecode JIT compiler. You can target the .NET platform in many languages, including but not limited to, Visual Basic .NET, C#, F#, C++/CLI (it’s NOT the C++ you know!), etc

Interestingly, you can also compile normal C++ to .NET but it will have unmanaged code (i. e. code where memory allocations/deallocations are performed by you instead of the runtime, and pointers). WP7 requires that all code that runs on it be managed. This means that Qt cannot run on WP7, even though it may be compiled targetting the .NET platform and it would run on desktop operating systems.

C# is a multi-paradigm programming language developed by the father of Delphi. It is very powerful and looks a lot like C++2011. When I was learning C#, I couldn’t but think what the actual implementation of C# features were behind the scenes, in C and C++.

WPF is Windows Presentation Foundation (formerly known as Avalon), the technology (library) used for the GUI. In plain terms, it’s a library which provides accelerated everything for Windows applications: widgets, 2D, 3D, scalable graphics, etc

When developing UIs in WPF, you can either use C# code:

// Create a Button with a string as its content.
Button stringContent = new Button();
stringContent.Content = "This is string content of a Button";

// Create a Button with a DateTime object as its content.
Button objectContent = new Button();
DateTime dateTime1 = new DateTime(2004, 3, 4, 13, 6, 55);

objectContent.Content = dateTime1;

// Create a Button with a single UIElement as its content.
Button uiElementContent = new Button();

Rectangle rect1 = new Rectangle();
rect1.Width = 40;
rect1.Height = 40;
rect1.Fill = Brushes.Blue;
uiElementContent.Content = rect1;

// Create a Button with a panel that contains multiple objects 
// as its content.
Button panelContent = new Button();
StackPanel stackPanel1 = new StackPanel();
Ellipse ellipse1 = new Ellipse();
TextBlock textBlock1 = new TextBlock();

ellipse1.Width = 40;
ellipse1.Height = 40;
ellipse1.Fill = Brushes.Blue;

textBlock1.TextAlignment = TextAlignment.Center;
textBlock1.Text = "Button";

stackPanel1.Children.Add(ellipse1);
stackPanel1.Children.Add(textBlock1);

panelContent.Content = stackPanel1;

or use XAML, which is an XML-based language for WPF:

<!--Create a Button with a string as its content.-->
<Button>This is string content of a Button</Button>

<!--Create a Button with a DateTime object as its content.-->
<Button xmlns:sys="clr-namespace:System;assembly=mscorlib">
  <sys:DateTime>2004/3/4 13:6:55</sys:DateTime>
</Button>

<!--Create a Button with a single UIElement as its content.-->
<Button>
  <Rectangle Height="40" Width="40" Fill="Blue"/>
</Button>

<!--Create a Button with a panel that contains multiple objects 
as its content.-->
<Button>
  <StackPanel>
    <Ellipse Height="40" Width="40" Fill="Blue"/>
    <TextBlock TextAlignment="Center">Button</TextBlock>
  </StackPanel>
</Button>

 

More or less, WPF is to .NET what QML is to Qt.

Ouch. This WP7 is completely different to what we are used to. Maybe we can make them less different?

People tend to believe WPF and XAML are the same thing. They are not. XAML is one of the languages (which happens to be used by 99.99% of the people) to write applications in WPF but it is not the only one. You can write WPF applications in C# code (it’s not unusual to mix XAML and C#, what we call “code behind” in WPF parlance), or you could create your own XAML-equivalent language.

Or you could make my wish for today true: create a compatibility layer for QML to be able to develop WPF applications in QML, effectively replacing XAML. It is technically possible. This will also require a glue-layer for C#, similar to what we have now to bridge QML and C++. This would make porting applications from C++ and QML to C#, QML and WPF a relatively easy task, and may provide realistic path to convert Qt applications to WP7 withouth a full rewrite.

Update Fixed XAML vs C# code, thanks ‘aa’. Also, please note using C++ with QML WPF would be straightforward

A wish a day 8: Wt Creator

by ⋅ 5 Comments

April Fools’ passed, it’s safe to blog again 🙂

My last wish was born when Koen Deforche (one of the best software developers I know) made an innocent comment at my talk at FOSDEM talk this year.

Koen happens to be the guy who created Wt (pronounced ‘witty’), a C++ library and application server for developing and deploying web applications. The API mimics Qt‘s: it is widget-centric and offers complete abstraction of any web-specific application details. Where Qt has QObject, Wt has WObject; where Qt has QPainter, Wt has WPainter; both provide a very similar Model-View architecture, both have signals and slots (Wt’s being based on Boost), both provide an OpenGL widget (WebGL in the case of Wt), both allow for language translations, and in fact you can combine Qt and Wt code thanks to the wtwithqt bridge.

If you know me, you know I love Wt. Developing webapps like they were desktop apps (thinking of “widgets” instead of “pages”) is very powerful. In fact, I gave up on Rails after I discovered Wt because Rails has become a spaghetti of Ruby, Javascript, CSS, HTML and whatnot, with so many conventions that make it very difficult to follow the code unless you know very well every library involved (not to speak of performance and memory consumption, where Wt beats everything).

Wt is not without its problems, though. In my opinion, the main needs of Wt are more widgets and an IDE. Today I’m going to talk about the IDE.

Read More →