I installed the GtkSharp 3.22.24.36 package via Project > Add NuGet Packages..., which completed successfully. But now Monodevelop can't decide which version of GtkSharp to use (3.22.24.36 or the in-built one, 2.12).
If I uncheck gtk-sharp in the Edit references... dialog, it tells me that I can't use the UI designer without it.
How do I get Monodevelop to use the downloaded GtkSharp (3.22)?
MonoDevelop comes with a custom version of Gtk2 + Xwt bundled. If you plan to use Gtk3, then the designer must be deactivated, since it won't work with Gtk3.
My advice, anyway, no matter which toolkit you use, is to avoid using the designer. As soon as you involve the designer, you code heavily depends on the IDE you use (Visual Studio, MonoDevelop, NetBeans... you name it).
Creating user interfaces "by hand" is no longer traumatic as it was in the 90's with the Windows API. For example, you can find a very good Gtk# tutorial in ZetCode.
User Interface Toolkits are actually very similar, they change the name of widgets and sometimes provide a slightly different layout, but they are all mostly the same, no matter it is WinForms or Gtk(for C#), Swing (Java), or Qt (C++ and others).
I know its an older question but things changed. Abandon MonoDevelop, just use the .NET Standard bound implementation of GtkSharp. You can then literally design interface using glade xml files, using official Glade application from GTK+. You can find it here.
With the current push from MS to abandon Framework in favor of Core, we finally succumbed when we figured out they will kill Framework (which they just did with .NET 5 announcement), but we also used the opportunity to investigate other options for our ports of LoBs to core. We discovered GtkSharp as WinForms replacement and AvaloniaUI as WPF replacement, which not only work perfectly but also truly work cross-platform. We ported several applications already and actually moved more then half of business work stations from Windows to Linux.
I need to know when inFullscreen of monitor object is set to true, I wanna make sure it's not set to true when window is maximized. I can't find any docs for imports.ui.main nor any imports.ui.*. That's simple (but still annoying) I can hold alt and press F2 and type lg then enter to try it in the repl. But what if I need some info about queueDeferredWork?
Or what if I wanna know if there's a signal like switch-workspace but when the switch is finished (when switch-workspace is triggered it SEEMS that the switch animation just began and at least inFullscreen doesn't return true when I switch to a fullscreen workspace, it just SEEMS so, I can't make sure as I can't find docs for it.)
Is gnome-shell api (except imports.gi.*) not documented? or am I missing something?
There was very similar question asked here: How do I get the monitor of an active window in GNOME?
Sorry I didn't see your question earlier; you should use the tags [gnome-shell-extensions] and [gjs] to ellicit help for more programming related questions.
Updated September 2021
As of, well awhile ago, GJS has its own portal for tutorials, documentation and so on.
https://gjs.guide
Everything below is linked to from this portal, so it's a good bookmark.
There are guides covering all the basics, much of the advanced usage, introductions to core libraries like GLib and GTK, including some specialized tutorials like spawning subprocesses. There is also a dedicated section for extensions, covering creation, translations, preferences and porting guides to get your extension working on the latest release.
Please - do request any documentation you find lacking. It may not always be feasible or quick, but we'll do our best.
https://gjs-docs.gnome.org
This is GJS's official API documentation for the GNOME platform, including all core libraries and all the other libraries like GStreamer and WebKit you expect. If a library is missing, you can request it by opening an issue.
For GNOME Shell extensions, these will be of particular interest (see the Architecture page for more details):
Clutter: The compositor-side toolkit, part of Mutter
Meta: The window manager and/or compositor (aka Mutter)
St: Builds on Clutter to add more complex widgets and CSS
Shell: The internal library of GNOME Shell, providing several classes and functions
Gvc: High-level bindings for PulseAudio. Not strictly a part of GNOME Shell, but used by it and worth noting.
This documentation is still correct, however it is probably best for those familiar with the GNOME platform that just need some hints for GJS.
Modules built into GJS: https://gitlab.gnome.org/GNOME/gjs/blob/master/doc/Modules.md
General API usage in GJS: https://gitlab.gnome.org/GNOME/gjs/blob/master/doc/Mapping.md
As JavaScript is (now) evolving fairly quickly, it is highly advised you familiarize yourself with GNOME Shell's JavaScript source. Aside from being crucial to writing extensions, this is the best way to keep up with new features in JavaScript and GJS, including patterns for using them.
HELP!
discourse.gnome.org using the extensions tag
Matrix: https://matrix.to/#/#extensions:gnome.org
IRC: irc://irc.gnome.org/shell-extensions
I have a project that uses both PHP and Python, and I would like to use JetBrains IDEs (in this case PhpStorm and PyCharm) to work with both languages.
However when I open the project using both IDEs concurrently I get a pop up whenever I switch from one to the other, as the newly focused IDE detects metadata that has been written to the project directory by the other IDE. I imagine this would be a problem between other combinations of JetBrains IDEs as well (hence the use of the generic jetbrains tag).
I have a work around (I will post in an answer for others to view), but it is somewhat awkward to set up, and I may well be working with other projects that use the same combination of languages.
Is there an easier solution?
My current workaround:
Create a new directory separate to the main project directory - using the language specific IDE for the second-most used language in the project, open the new directory as a project, and using the options in Settings > Project > Project Structure, add the main project directory as a separate content root.
Whenever needing to work on the parts of the project written in the secondary language, you can now open the new directory instead; this keeps metadata for both IDEs separate.
A workaround which allows for two IDE's to share the same directory without IDE settings conflicts.
JetBrains software allows you to store project settings as either a file based project (*.iml), or a directory based project (.idea).
To choose file or directory based projects, change the file storage type when opening a project.
Note: Directory based projects are preferred to file based projects, as they allow for versioning of shared settings. Support for file based projects is deprecated and may be removed.
With latest phpStorm 9 we have new feature called simultaneous tags editing.
This is generally very nice feature that i'd like to use, but i have one old project with very bad code with a lot of mixed PHP, HTML and JS code, where it breaks code.
I know i can disable this in settings->editor->General->simultaneous tag editing, but it disables this feature for whole phpStorm. Is there way to disable it only per one project?
Is there way to disable it only per one project?
Nope -- this is an IDE-wide setting.
The only possible solution I can think of is to have separate PhpStorm installation that will use custom folders to store IDE settings (look into idea.properties file from PhpStorm distribution, e.g. on Windows 7 it would typically be %PhpStorm-Install-Folder%\bin\idea.properties).
With IDE settings stored in different location you can now configure this installation with different settings (e.g. have that option turned off). Obviously, all settings here will be different to your original setup, unless you configure it the same way or will keep certain config files synced (e.g. Keymaps, Color, Web Servers, Live Templates and other things could easily be synced on file level).
Just remember to launch this installation when you want to work with that specific project.
Now that TideSDK is effectively dead, I've been looking into alternative 'wrappers' to run HTML/CSS/JS applications as stand-alone desktop applications. The three viable options I have run across so far, are NW.js (formerly node-webkit), brackets-shell, and Electron (formerly atom-shell).
The problem is that there does not appear to be a sufficiently complete comparison between the three in terms of feature set, compatibility, etc. I'm hoping to turn this into a more-or-less canonical thread on the (objective) differences between the three, in particular regarding:
Platform support; operating systems, dependencies, etc.
Language feature support, as far as HTML5, CSS3 and JavaScript are concerned. Think things like "does HTML5 video work, and if yes, what codecs are available?"
Non-standard extra features, such as tray icons, popup notifications, and OS-rendered menu bars.
Extensibility; eg. ability to 'plug in' native code, talk to Node.js, and so on.
Architecture; in particular the architectural differences that affect daily usage as a developer.
Debugging; included development tools, compatibility with commonly used tools like node-inspector, etc.
... and so on.
What are the objective, technical differences that matter when making a choice between them as an application developer?
I did similar research about two months ago, and in the end I went with node-webkit. The biggest upside on node-webkit is node.js and npm. The package management of npm is really nice, and node has well done filesystem access.
Brackets-shell looked interesting, but other than a nice IDE I didn't really get what made this one as good or better than the rest. They are very clear that "The brackets-shell is only maintained for use by the Brackets project ", that screams run away to me.
https://github.com/adobe/brackets-shell#overview
Atom-shell seems to be recently active, but it seems much like brackets in that they are really writing and editor/IDE that just happens to be attached to a webkit runtime. It also is built on top of node.js. This one has the downside of being difficult to search for stuff online without being reminded of your middle school chemistry.
I really don't want an new editor, and most programmers have their favorite already. For the actual application development, they pretty much work the same, and should, since they all use webkit. You basically write 90-95% of it like a website, and then deal with the native parts, and some config.
These things are true for all three of them
platforms - runs on Windows, Mac, and Linux
language support - HTML5, CSS3 and Javascript : since they run javascript you can download and run nearly any library/framework that you want.
The big caveat on webkit is codec support. Typically you will have problems with non-free video codecs, unless you rebuild the dll/so to support them. For example the shipped node-webkit won't play mp4 video.
I've been playing with Atom-Shell over the last few days, and I am loving it so far.
The best part about it is that it's backed by GitHub.. which should allow you to settle into the platform for the long term, especially if it gains a large following. It's also made possible by direct Node.js improvements courtesy of a contract with StrongLoop, who is a major Node.js contributor (they claim to employ more Node.js core developers than any other company, even Joyent).
I've also found it rather comfortable to get started. It took me about a day to learn the structure and get my first proof of concept running. Very cool.
Bullet Points:
Platform support: Windows, Linux, Mac OSX (More Info Here)
Language feature support: HTML5, CSS3, JS via Chromium - so far, zero issues, but I have not tested video specifically.
Native Features: Native App Menus, Task Tray Support, Global Hotkeys, Protocol Handler Support (that I've seen so far)
Extensibility: Excellent Node.js integration, both the client and server can "require" Node.js modules and natives. I've also successfully tested Bower libraries (incl jQuery) without issue.
Architecture: Covered in the other points, but in general its very smooth.
Update (11/25/14): I've not yet found use case for Atom-Shell in any official capacity, but I have used it to build a few small apps for my own use, the most complex being an app that pulls my time logs from my PM software and creates Paypal invoices.
My opinion of the platform remains positive. It's pretty awesome.
On my time invoicing app I successfully brought in Bootstrap 3's Dashboard Example Template and a few node modules (bluebird, Paypal SDK, Teamwork PM Client) to create a mildly complex app. It took me a few days and does its job well.
I really cannot think of anything negative to say about Atom-Shell, its solid, stable, fast, and easy to code for. I hope this helps someone.
Besides fully support Web standards, NW.js supports a list of non-standard features for native app development including:
Protect JS source code by compiling them into machine code: https://github.com/nwjs/nw.js/wiki/Protect-JavaScript-source-code-with-v8-snapshot
Jailed devtools: https://github.com/nwjs/nw.js/wiki/Devtools-jail-feature
Additional security model with which you can do more in DOM: https://github.com/nwjs/nw.js/wiki/Security https://github.com/nwjs/nw.js/wiki/Changes-to-DOM
enhanced file dialog: https://github.com/nwjs/nw.js/wiki/File-dialogs
kiosk mode: https://github.com/nwjs/nw.js/wiki/The-Kiosk-mode
supports for a growing list of chrome.* API, include chrome.webRequest so you can intercept HTTP requests from DOM: https://github.com/nwjs/nw.js/issues/518
support for rich notifications, print preview, many more chrome.* APIs, Chrome Apps and other Chromium features starting from 0.13.0-alpha0
There is much more to see in the wiki including Menu, Tray, etc.
I've been working with brackets-shell for some time now, here are some of my findings:
brackets-shell is primarily developed as a shell under the brackets IDE project, but the project can run any web application. You just need to point it to your own html page. Clint Berry wrote an excellent tutorial about doing just this: http://clintberry.com/2013/html5-desktop-apps-with-brackets-shell/
The project is backed by Adobe and has a lot of activity
Documentation could be better
platform support They support Windows, Mac and Linux. An installer package can also be created. I only tested it on Win and Mac, it works great.
feature support html5, css3, js. Html5 video does not work out of the box, but is very easy to enable (by default the ffmpegsumo.dll is not copied into the installer, if you change the script to copy it it will work).
native features menu bar, 'open file with', file system access. I am not using any of these, as all I need is the communication with the node process.
extensibility a nodejs is built in, and you can communicate with node from your web application. In this way, you can use node to access the filesystem etc.
architecture The project is well set up, keeping a nice separation between the shell project and your own web app running inside it. In your own application, a global appshell object is available which gives you access to the brackets functionality (filesystem access, communication with node process, ...).
One thing to note (if you care), is that the Electron officially does not support Windows Vista. Vista's market share is about halfway between OSX 10.9 and 10.10 (both of which are fully supported by Electron). Vista is also still supported by Microsoft until 2017.
NW.js works fine in Vista, as well as OSX 10.9+. NW.js works on Ubuntu, Debian, Zorin, Manjaro, Arch, and most other Debian based Linux OS's. Electron has refused PR's to fix Ubuntu specific bugs on their platform which is concerning.
NW.js works in XP too. Currently 18% of the market is still on XP. So if you're desktop application is more general purpose or wants to have access to the late adopters still on XP, you're probably better off with NW.js (0.14.7) as Electron only supports Win 7 and up.
If you use NW.js 0.12.3 you can also support OSX 10.6+ and very old versions of Debian based Linux OS's like Ubuntu, and Win XP+. It is recommended that you do special builds just for those legacy systems though and use the newer versions of NW.js for newer OS's.