Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Linux support #13

Closed
wants to merge 5 commits into from
Closed

Add Linux support #13

wants to merge 5 commits into from

Conversation

tschuy
Copy link
Contributor

@tschuy tschuy commented Sep 21, 2015

Like you noted in #11, this essentially boils down to putting the app.dock into an if statement. (I don't think there's any Linux equivalent to the dock icon with a number on it, or the bouncing dock icon.)

I also rearranged the menu to be more cross-platformy, since there's no appname menu on most distributions of Linux. (Though there is in Gnome 3, the desktop manager I use, but I couldn't figure out how to add to it from Electron, and Atom doesn't use it either.)

There is a bug with desktop notifications crashing (electron/electron#2294) that seems pretty awful. The issue isn't entirely clear which versions of what it presents itself on, so I added a note to the README about it. The notifications themselves work just fine, and as long as you don't click on them, the system won't crash.

I would be happy to make any changes you need before merging this. I could also test it on a non-Gnome environment.

}
}
);

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the menues are so different on OS X and Linux I think it would be better to just create a separate file with a Linux menu instead of juggling this mess. The Help menu is common and can be a menu-common.js file and required into each.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's reasonable. It started out not too bad, and then as I added more and more to it, it got crazier and crazier 😛

@sindresorhus
Copy link
Owner

Make sure the Linux menu is consistent with other Linux apps.

type: 'separator'
},
{
label: 'Preferences...',
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re #13 (comment)

On Linux it's only Preferences, not Preferences....

@tschuy
Copy link
Contributor Author

tschuy commented Sep 21, 2015

Unfortunately, About goes under help on Linux, so I can't actually factor out the help menu. 😢

From what I managed to get by messing around with electron-packager the best I'll be able to do is make an executable that can then be zipped up, it doesn't have a way to create a single runnable file. I'll make the script throw the build into a zip.

@tschuy
Copy link
Contributor Author

tschuy commented Sep 21, 2015

what would you prefer the behavior of npm run build be? it's constrained by running /bin/sh, not /bin/bash, so I can't do something fancy like if [[ "$OSTYPE" == "linux-gnu" ]]; then npm run build-linux; else npm run build-osx; fi. I could write a separate build.sh script that compiles your current system, or I could just make it run OS X by default, or both?

@sindresorhus
Copy link
Owner

npm run build should build for both platforms. electron-packager can handle this fine. See its docs.

@tschuy
Copy link
Contributor Author

tschuy commented Sep 21, 2015

When trying to build them together, I run into the following problems:

  • sign doesn't exist on Linux, but electron-packager still tries to use the codesign executable, so it crashes
  • it doesn't appear to want to put the executable into an archive, even when -asar is set
  • for whatever reason, instead of setting the app icon at compile time, it's set in the source code as the icon value passed to BrowserWindow. However, media/ isn't included in the build, so there's no static file to reference.

I think two separate build commands might be necessary for that top reason. For the bottom two, I'm sure it's just me being silly and missing something in their documentation. (I still have no idea what asar is supposed to look like when it's successfully outputted.)

@sindresorhus
Copy link
Owner

sign doesn't exist on Linux, but electron-packager still tries to use the codesign executable, so it crashes

Ugh, electron-packager is so buggy. Wish we had something better...

I'm ok with just being able to build from OS X. I'm the only one that creates builds anyways. Having one build massively simplifies it, so I think it's worth the limitation.

it doesn't appear to want to put the executable into an archive, even when -asar is set

Can you elaborate? It's the zip command that does this, not electron-packager.

for whatever reason, instead of setting the app icon at compile time, it's set in the source code as the icon value passed to BrowserWindow. However, media/ isn't included in the build, so there's no static file to reference.

The media folder is ignored. I guess we can ignore everything in the media folder, except the icon.

@tschuy
Copy link
Contributor Author

tschuy commented Sep 21, 2015

Can you elaborate?

from electron-packager's docs, it reads like asar should put everything into an archive: https://github.com/maxogden/electron-packager#usage

for now, I've just set the build-linux command to stick it into an archive itself.

What I could do is have build-linux and build-osx commands, and just have build be npm run build-osx && npm run build-linux. This would still be one command, and it'd allow anyone that wants to run builds themselves (though you're right that people working on the project have no reason to build, only you) to just run the build they want. I don't know if this would break some caching mechanism that electron-packager has, though.

I tried removing media/ from the build command for Linux and it's not included in the dist/Caprine-linux-x64 folder, so I'm going to look more into it.

@tschuy
Copy link
Contributor Author

tschuy commented Sep 21, 2015

ok, I have a solution that more or less works, as far as I can tell. It should allow you to create a Linux zip and an OS X zip by running build, and allow others to create zips for either system by running build-osx or build-linux. The Linux build has a functioning icon, and I included a .desktop template in the README for anyone who wants to create a shortcut. Since this isn't using a proper install mechanism (which is to say, a deb or rpm), installation is a little clunky.

${app.getName()} ${app.getVersion()}
${process.platform} ${process.arch} ${os.release()}`;
${app.getName()} ${app.getVersion()}
${process.platform} ${process.arch} ${os.release()}`;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't indent this. Template literals are whitespace sensitive.

}
},
{
label: `About ${appName}`,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On Ubuntu it's just About.

Look at the existing Linux menues to make sure everything is consistent.

@sindresorhus
Copy link
Owner

Is there any way to have the app installable on Linux with something like Homebrew Cask on OS X?

If https://github.com/loopline-systems/electron-builder supported Linux we could use that. Maybe worth opening a feature request for that?

@adam-stokes
Copy link

We could look at how atom builds their deb's/rpm's and mimic that. Would at least support the major distributions

@tschuy
Copy link
Contributor Author

tschuy commented Sep 25, 2015

I've addressed your feedback about the menus and fixed the accidental inclusion of linux in the build-osx command.

For menu consistency, I'm not sure there's a really good standard compared to what there is on OS X. I tried to go off of Gedit. Most Gnome apps use the menu at the top of the screen (that I've not seen any other app use, and don't think there's support for in electron), but gedit has a more traditional File / Edit / Help etc.

You mentioned that the edit menu shouldn't have some of those items, but gedit has all of them. I've left them there for now; which ones were you thinking of?

About packaging -- I don't think there's a good way to distribute this unless we make it build an RPM and a DEB. I'll make a feature request on https://github.com/loopline-systems/electron-builder, and revisit this later if they add support.

@tschuy
Copy link
Contributor Author

tschuy commented Sep 25, 2015

Also, I'd be more than happy to squash these commits if you want so that address feedback isn't in the git log.

@tschuy
Copy link
Contributor Author

tschuy commented Sep 25, 2015

issue for adding linux support to the builder: electron-userland/electron-builder#7

@adam-stokes
Copy link

You mentioned that the edit menu shouldn't have some of those items, but gedit has all of them. I've left them there for now; which ones were you thinking of?

I think it just depends on the application, things like gedit, kate, mousepad, etc make use of those edit menu items where as others don't. They probably are useful for any type of text editing but I'm not sure this app needs menu items for it. Take for example Telegram on the desktop for Linux, it doesn't contain any of those menu items (File, Edit) etc.

@sindresorhus
Copy link
Owner

@tschuy Landed! Really appreciate you working on this :)

@sindresorhus sindresorhus mentioned this pull request Sep 29, 2015
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants