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).
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”.
This is a short one and probably doable as a Summer of Code project.
The idea: add support for the Microsoft compiler and linker and Visual Studio projects and solutions (.sln, .vcproj, et)c in KDevelop, at least in the Windows version.
QtCreator has suport for the first part (compiler and linker).
For the the second part (solutions and projects), code can probably be derived (directly or indirectly) from MonoDevelop‘s and CMake‘s. The starting point would be MSBuild support, as it’s what VS2010 is based on.
Bonus points if you add C#/.NET support (Qyoto/Kimono).
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!
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.
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).
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!
Do you use WCF? Do you generate your datacontracts by means of postbuild events? Have you tried msbuild and seen a “cannot build XXXXX.csproj because DataContracts.cs was not found” error? Then keep reading.
What
MsBuild is the “next generation” nmake for Visual Studio. It’s been available since .NET 2.0 and has been bundled with Visual Studio since MSVC2008.
Same project files…
You don’t need to feed msbuild special project files (such as the Makefiles nmake required), it is smart enough to understand Visual Studio solutions.
… yet slightly different behavior
MsBuild does not behave 100% like Visual Studio (devenv), specifically in regards to:
Dependencies
When events are run
When byproducts and referenced projects are copied
In general, this will affect you whenever you use postbuild events to generate source code or binaries which are required immediately.
In the project I am involved now, this is especially important when generating datacontracts. We use a Visual Studio post-build event.
Dependencies
There are two kinds of ways to express project-to-project dependencies:
Project to project references (Add Reference->Project tab) [this mechanism also handles gathering the referenced output file as well]. For .csproj, this is persisted as a <ProjectReference> item in the project file.
Explicitly specified dependencies (Solution properties->Project Dependencies) [with this mechanism you would usually also add a File Reference to the referenced output yourself]. This writes the “ProjectSection(ProjectDependencies)” section in the .sln.
There seems to be a long standing bug which makes msbuild not take all the dependencies into account.
As a consequence, a solution may build fine in Visual Studio (devenv) but not build at all with msbuild. I would say this bug is fixed in VS2010SP1, but I cannot tell 100% sure because I have not performed enough testing.
In addition to that, never add a dependency as a reference-to-DLL if that DLL is part of of your solution (.sln). Both MsBuild and DevEnv will choke when you switch from Debug to Release, because you would be setting a reference to a Debug DLL from a Release project, or viceversa (unless you use $(ConfigurationName) in your path, of course, but people rarely remember to do that).
When events are run
MsBuild runs the postbuild event before copying the byproducts to the output path
Visual Studio (devenv) runs the postbuild event after copying the byproducts to the output path
This can be solved by writing an AfterBuild event manually in the .csproj, but it is quite inconvenient because there is no GUI in Visual Studio to add, edit or remove AfterBuild events. You are alone with your text editor.
When byproducts and references are copied
As said above, msbuild runs the postbuild event before copying the byproducts. No only that: msbuild runs the postbuild event before copying the referenced projects (DLLs) to the output path.
Visual Studio (devenv), on the other hand, runs the postbuild event after copying the byproduct and its referenced projects to the output path.
If you need the compilation byproducts in the post-build event (as is generally the case when generating datacontracts in the postbuild event), you will need a workaround.
You would think it’d be possible to tell MsBuild to behave like devenv, right? Wrong. It is not possible.
The only possible workaround I have found is to manually copy the result of the compilation to the output path in the postbuild event. Something like this:
call “%VS100COMNTOOLS%\vsvars32.bat”
if exist “$(ProjectDir)Temp” del /s /f /q “$(ProjectDir)Temp”