I went to Office UI Fabric's site today and noticed "Fabric.js" was removed as an option.
Is Microsoft discouraging it from being used?
Last version update for Office Fabric JS (office-ui-fabric-js package) happen 8 months ago and the latest commit was performed 3 months ago. In the same time office-ui-fabric-react package is regularly updating and moving on full speed. Make up your own conclusion. By the way, FYI Office UI Fabric JS has it's own website.
Office UI Fabric JS is now officially dead. Fabric React and Fabric Core are the recommended libraries to use going forward.
We received this email from the Office 365 Message Center today:
Do you have any internal line-of-business apps or add-ins that your
developers have made to look like Office? If so, they may be using a
library called Fabric JS. We want to inform you that we will no longer
be making updates to the Office UI Fabric JS, beginning October 1,
2019.
Over the past few years, the team behind Office UI Fabric has been
working hard on Office UI Fabric React. It is a robust framework for
building experiences that fit seamlessly into a broad range of
Microsoft products. It includes many full-featured, production-ready
UI components, utilities for accessibility, styling, iconography,
toolkits, resources for designers, and more. Having reached this
milestone, we’re simplify our offering of UI frameworks. Going
forward, we recommend developers use Fabric React and Fabric Core to
build experiences that align with the Office user experience. As a
result, October 1, 2019 marks the official end of support for Office
UI Fabric JS. While we are no longer actively developing new features
or fixing bugs, all existing versions of Fabric JS will remain
available on Microsoft’s CDN and solutions built with Fabric JS will
continue to function normally.
[How does this affect me?]
If you have, or are building, applications that leverage Office UI
Fabric JS, you’re welcome to continue using it; however, Microsoft
will not fix any bugs and offers no guarantee that components will
stay current with latest Office user experience.
[What do I need to do to prepare for this change?]
If you have, or are building, applications that you would like to
ensure fit seamlessly into a broad range of Microsoft products,
instead of using Fabric JS, we recommend using Fabric React or Fabric
Core. To learn more about Fabric React and Fabric Core, please see the
Additional Information.
Related
It is not clear to me if I can use fabricUI icons & Segoe UI font in my project
According to this license which can be found in the project repository
I have found this StackOverflow question which is linking to this issue in the Fluent Repo
Fabric's assets (fonts, icons, and product logos) are part of Microsoft's brand, and can only be used in apps & services--including commercial ones--that connect with Microsoft products. These include Add-ins for Office, web parts for SharePoint, and other extensions for Microsoft products. This applies to usage of the assets in application code itself as well as any designs produced by the toolkit.
I am building a commercial application that can be used as an Excel add-in and have a separate URL where can be used as a standalone web app. Can I use Fabric Icons and SegoeUI font in both places?
My application is 100% MS services dependent (MS Auth, multiple azure services) and I would like to have the same design.
I published an app to the App Store using Titanium Studio in 2013. I have recently found a bug in the code that I want to fix and publish.
I logged into Appcelerator's website to download the latest studio since it's been three years, only to find out that it's a paid platform now.
I just want to make a quick bug fix and publish. I don't need any of the services that come with the platform.
I realize there is a free SDK that you can compile yourself, etc, etc.
I don't mind paying for a $36 for one month only if it enables me to just publish a new version of my app.
My question is, if I publish the app after paying the $36 and then cancel my subscription, will the cancellation affect my app? Does the IDE inject some sort of "call home" time bomb?
I tried asking the support at appcelerator but they answered like a politician and dodged it.
Thanks for any help.
A published/compiled app has no direct connection with appcelerator. So if you cancel the subscription nothing happens.
However, if you use paid services... things might go wrong.
Statistics for example is a paid service. If you cancel subscription I assume the app keeps working but will make calls to their backend that most likely will fail (not sure about this). App should keep working.
If you use any cloud service (push notifications, arrow storage etc) your app will stop working of course.
If you don't use any of the services, you can just cancel and be done with it.
That said, if you just want to make 1 change to an app you could just dive in and compile without the Appcelerator Platform and just use the Open Source code.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
We are planning to built cross platform desktop application. We found that Node-Webkit is a perfect choice for us. But GitHub developed their own framework called Electron instead of using Node-Webkit.
What is the difference between them?
Electron has a page explaining the differences with nwjs.
Like NW.js, Electron provides a platform to write desktop applications
with web technologies. Both platforms enable developers to utilize
HTML, JavaScript, and Node.js. On the surface, they seem very similar.
There are however fundamental differences between the two projects
that make Electron a completely separate product from NW.js.
Entry of Application In NW.js, the main entry point of an
application can be an HTML web page. In that case, NW.js will open the
given entry point in a browser window.
In Electron, the entry point is always a JavaScript script. Instead of
providing a URL directly, you manually create a browser window and
load an HTML file using the API. You also need to listen to window
events to decide when to quit the application.
Electron works more like the Node.js runtime. Electron's APIs are
lower level so you can use it for browser testing in place of
PhantomJS.
Node Integration In NW.js, the Node integration in web pages
requires patching Chromium to work, while in Electron we chose a
different way to integrate the libuv loop with each platform's message
loop to avoid hacking Chromium. See the node_bindings code for how
that was done.
JavaScript Contexts If you are an experienced NW.js user, you
should be familiar with the concept of Node context and web context.
These concepts were invented because of how NW.js was implemented.
By using the multi-context feature of Node, Electron doesn't introduce
a new JavaScript context in web pages.
Note: NW.js has optionally supported multi-context since 0.13.
Legacy Support NW.js still offers a "legacy release" that supports
Windows XP. It doesn't receive security updates.
Given that hardware manufacturers, Microsoft, Chromium, and Node.js
haven't released even critical security updates for that system, we
have to warn you that using Windows XP is wildly insecure and outright
irresponsible.
However, we understand that requirements outside our wildest
imagination may exist, so if you're looking for something like
Electron that runs on Windows XP, the NW.js legacy release might be
the right fit for you.
Features There are numerous differences in the amount of supported
features. Electron has a bigger community, more production apps using
it, and a large amount of userland modules available on npm.
As an example, Electron has built-in support for automatic updates and
countless tools that make the creation of installers easier. As an
example in favor of NW.js, NW.js supports more Chrome.* APIs for the
development of Chrome Apps.
Naturally, we believe that Electron is the better platform for
polished production applications built with web technologies (like
Visual Studio Code, Slack, or Facebook Messenger); however, we want to
be fair to our web technology friends. If you have feature needs that
Electron does not meet, you might want to try NW.js.
Keep in mind this may be biased- it is from Electron's wiki page.
Electron doesn't introduce
a new JavaScript context in web pages.
Source code protection
Electron is packaging its applications with asar, which contains the applications' unprotected source code. This makes it possible for application 1 to extract application 2 and inject vulnerable scripts, without the user knowing it. You can checkout this project on GitHub to see an example of how to manipulate the Slack app for an example. As for now, the Electron team don't have any plans to implement support for source code protection.
NW.js has built in support for compiling your source code to protected binaries.
I've downloaded and installed the windows 8 consumer preview, and I'd like to figure out how to use the UI Automation API's to get data from metro style applications.
Background: I have a lot of automated tests which use the Microsoft UI Automation API's to interact with applications. The scripts are written in IronRuby against .NET 4
Initially, I'd simply like to check if the start menu is visible (and if so, close it)
According to Microsoft, the normal UI Automation API's should be able to access and control metro style applications, but the problem is, I can't figure out how my code can actually access the UI of metro applications? Our normal way of viewing UI automation data is using UISpy, however when I run UI spy under windows 8 and bring up a metro app, there is no mention of it... it seems like metro apps (including the start screen) are walled off from the desktop.
If I can't find the metro apps in UISpy, how can I find what their automation ID's are, and how could I find them from my automated test scripts?
A few resources on UI automation which works in Metro style apps:
Here is a sample demonstrating it.
Here is a blog post explaining it.
This is a forum thread on the subject.
There is nothing about the app that stops traditional UI automation from working correctly. You may have to get updated tools to view the Metro style apps. Some ship with the Consumer Preview. Look for inspect.exe.
UI Automation tools can automate Metro applications. Check RIATest for example.
Stating from version 6.0 a number of features in RIATest are specifically targeted at Metro style application automation, particularly:
Ability to stay on top of Metro UI to allow you to simultaneously see your Metro application and RIATest IDE and minimize switching from Desktop to Metro screens when automating a Metro application.
Recording of actions performed on native Windows GUI elements (including Metro GUI). The recorder analyses your script code and reuses your variable names to generate cleaner recorded scripts similar to how you would hand-code an automation script.
Seamless workaround for bugs like this in Windows UI Automation implementation in Metro UI.
Disclaimer: I work for Cogitek, the RIATest company.
WinRT (aka "Metro Style") applications run in an sandbox. You cannot pierce the walls between applications, including to Desktop applications. This includes network isolation (you cannot refer back to localhost for example except in a development environment). There are a couple of exceptions to this such as the Share and Search contacts which allow for very specific types of interactions between apps.
It is this sandbox that is preventing UISpy from seeing the executing WinRT application in the background. I'm not sure how UISpy could work around this issue without some kind of development environment exception to the sandbox (similar to the network isolation exception) that isn't available in the consumer preview.
I'm also unaware of any announcements regarding when/if the UI Automation API will be supported for WinRT applications at this time.
How can I develop an installable desktop application on top of the Mozilla Engine or the Webkit engine.
We want to have best of both worlds, ease of development with DOM+Javascript+RenderingEngine+ContinuedImprovements in a Browser and user's control as in a desktop app
I looked at using C++ XPCOM for Mozilla but it seems to be quite complicated, Is there any other way to code like a WebApp using Javascript but burn it into the browser and dress it to give a feel of a desktop app. Also I require that javascript is compiled into native so that one cannot sneak into the source code
Are there any examples of desktop applications done this way ?
Web apps are fine but there are concerns of piracy, privacy, security and version control. The moot point is that in a web app the control lies with the software vendor, moreover the data is also with the vendor. Not only these, any changes to the application may also necessitate another around of training. What we want is that once the customer buys a version he is sure of what he owns and that he is in total control of it and we as software developer do not exposed our source code.
The issue is we have expertise in Web App development and we want to utilize that to develop a Desktop App
Your last point is that :
The issue is we have expertise in Web App development and we want to utilize that to develop a Desktop App
Well then BowLine can be an option though it requires Ruby, so you need to consider that. You can also take a look at WebKitDotNet if you are with .net Background.
Use XUL for the user interface and code your functions using JavaScript. You problably only need C++ to expose native functionality not yet available in Gecko. Examples of software that works this way: Komodo IDE, Songbird, Firefox and Thunderbird.