Creates a desktop file and icon so that Bombadillo can show up in desktop environment menus and launchers #93

sloum · 2019-11-15T05:51:52Z

sloum commented

2019-11-15 05:51:52 +00:00

Includes bombadillo.desktop in repo
Includes basic bombadillo icon in repo (I just whipped up something quick, I'm open to suggestions for the icon itself)
Adds install-desktop makefile target
Updates makefile install and uninstall targets

- Includes `bombadillo.desktop` in repo - Includes basic bombadillo icon in repo (I just whipped up something quick, I'm open to suggestions for the icon itself) - Adds `install-desktop` makefile target - Updates makefile `install` and `uninstall` targets

asdf was assigned by sloum

2019-11-15 05:51:52 +00:00

sloum self-assigned this 2019-11-15 05:51:52 +00:00

sloum added the

enhancement

non-code

labels 2019-11-15 05:51:52 +00:00

sloum commented

2019-11-15 05:54:31 +00:00

To create this I used the following resources:

It seems that there are more things that can be done as well, but some of it was confusing and I was able to verify that this works well (on my system at least), so did not want to spend a ton of time on this one.

You mentioned making it so that gopher/gemini links could be opened in bombadillo by default. I could not figure out how to get that set up, but would love for that to happen. Let me know, or update this branch, if you know how to do it.

To create this I used the following resources: - https://wiki.archlinux.org/index.php/Desktop_entries - https://help.ubuntu.com/community/UnityLaunchersAndDesktopFiles - https://specifications.freedesktop.org/menu-spec/menu-spec-1.0.html It seems that there are more things that can be done as well, but some of it was confusing and I was able to verify that this works well (on my system at least), so did not want to spend a ton of time on this one. You mentioned making it so that gopher/gemini links could be opened in bombadillo by default. I could not figure out how to get that set up, but would _love_ for that to happen. Let me know, or update this branch, if you know how to do it.

sloum commented

2019-11-15 06:22:11 +00:00

Ok. I figured it out and updated the desktop target to add default mime entries for: gopher, gemini, and finger. I figure http(s) and telnet are already fine with system defaults.

I have tested this on my system. After installing I can type a gemini link into firefox and it will ask me if I want to open it in bombadillo (there is a box to not be asked again and just do it from now on, but it does ask first so-as to not overwrite other defaults). It totally works: brings up a new terminal window with bombadillo opened to the url in question. This is really really cool.

Ok. I figured it out and updated the desktop target to add default mime entries for: gopher, gemini, and finger. I figure http(s) and telnet are already fine with system defaults. I have tested this on my system. After installing I can type a gemini link into firefox and it will ask me if I want to open it in bombadillo (there is a box to not be asked again and just do it from now on, but it does ask first so-as to not overwrite other defaults). It totally works: brings up a new terminal window with bombadillo opened to the url in question. This is really really cool.

sloum commented

2019-11-16 00:29:18 +00:00

If we want to modify the makefile further to support BSDs or do Darwin specific actions this is a good reference:

https://en.wikipedia.org/wiki/Uname

If we want to modify the makefile further to support BSDs or do Darwin specific actions this is a good reference: https://en.wikipedia.org/wiki/Uname

asdf commented

2019-11-16 20:28:48 +00:00

It's impressive. Really adds a lot of usability to a desktop environment.

I'll need a bit of time to absorb this as it's all new to me.

This doesn't seem like it is compatible with running sudo make install as the xdg-mime commands look user specific (it tries to install to the root user).

xdg-mime's man page refers to an install function, as well as a --mode setting designed to handle system installs. Can some of these help?

It's impressive. Really adds a lot of usability to a desktop environment. I'll need a bit of time to absorb this as it's all new to me. This doesn't seem like it is compatible with running `sudo make install` as the xdg-mime commands look user specific (it tries to install to the root user). xdg-mime's man page refers to an install function, as well as a --mode setting designed to handle system installs. Can some of these help?

sloum commented

2019-11-16 20:35:45 +00:00

Strangely, I installed with sudo make install and all of it did work. It is all pretty new to me as well, so there may be much better ways to go about this. I looked into supporting OSX with this but their way of handling this sort of thing is much more complicated and looks harder to automate, particularly if we aren't using a .app file.

I'll look into the --mode and install function and see what I can get figured out. In the meantime, feel free to play around with this or update it with any findings. :)

Strangely, I installed with `sudo make install` and all of it _did_ work. It is all pretty new to me as well, so there may be much better ways to go about this. I looked into supporting OSX with this but their way of handling this sort of thing is _much_ more complicated and looks harder to automate, particularly if we aren't using a `.app` file. I'll look into the --mode and install function and see what I can get figured out. In the meantime, feel free to play around with this or update it with any findings. :)

sloum commented

2019-11-18 00:27:30 +00:00

The man page shows the following in regard to the mode flag:

The default is to use system mode when called by root and to use user mode when called by a non-root user.

That explains why it worked from the Makefile when using sudo. I think we should be ok as is. We could add explicit instructions to use system, but it doesnt seem to be necessary.

The man page shows the following in regard to the `mode` flag: `The default is to use system mode when called by root and to use user mode when called by a non-root user.` That explains why it worked from the Makefile when using sudo. I think we should be ok as is. We could add explicit instructions to use system, but it doesnt seem to be necessary.

sloum commented

2019-11-19 17:17:08 +00:00

Taking a look at things, this is the only non-documentation story left for the release. Once we decide what to do about this PR I think we are feature complete for 2.0.0 and should push any code changes into a separate branch for a next version (branch to be set up when/if needed).

Once this is merged in and any documentation changes are added to support it I think we are at the stage for this repo where we just need to do final passes on README (me) and manpage (you). At that point we will have the web and gopher reviews to finish and then launch and do the reach out to various places to get people using it :) It feels like the finish line is in sight!

Taking a look at things, this is the only non-documentation story left for the release. Once we decide what to do about this PR I think we are feature complete for 2.0.0 and should push any code changes into a separate branch for a next version (branch to be set up when/if needed). Once this is merged in and any documentation changes are added to support it I think we are at the stage for this repo where we just need to do final passes on README (me) and manpage (you). At that point we will have the web and gopher reviews to finish and then launch and do the reach out to various places to get people using it :) It feels like the finish line is in sight!

asdf commented

2019-11-19 21:44:21 +00:00

Sorry I think I had been subconsciously avoiding this because of our last jaunt with xdg-open.

I'm still getting these errors when running sudo make install

xdg-mime default bombadillo.desktop x-scheme-handler/gopher
touch: cannot touch '/root/.config/mimeapps.list': No such file or directory
/usr/bin/xdg-mime: 848: cannot create /root/.config/mimeapps.list.new: Directory nonexistent
xdg-mime default bombadillo.desktop x-scheme-handler/gemini
touch: cannot touch '/root/.config/mimeapps.list': No such file or directory
/usr/bin/xdg-mime: 848: cannot create /root/.config/mimeapps.list.new: Directory nonexistent
xdg-mime default bombadillo.desktop x-scheme-handler/finger
touch: cannot touch '/root/.config/mimeapps.list': No such file or directory
/usr/bin/xdg-mime: 848: cannot create /root/.config/mimeapps.list.new: Directory nonexistent

I'm doing this on Ubuntu 19.10. I'm not sure why this works for you, or maybe it only appears to work for you. I need to research this further, but:

This fails because my /root directory does not have a ./config directory
I don't understand how xdg-mime could set my default assosciations by placing files in /root, a directory I can't read
The man page says that 'xdg-mime default' should not be run as root, probably for this reason(???), but how are you meant to set a system-wide default? The --mode setting only refers to installing and uninstalling, but that's a different thing?

I'll do some more reading to try to understand this and let you know what I find out.

Sorry I think I had been subconsciously avoiding this because of our last jaunt with `xdg-open`. I'm still getting these errors when running `sudo make install` ``` xdg-mime default bombadillo.desktop x-scheme-handler/gopher touch: cannot touch '/root/.config/mimeapps.list': No such file or directory /usr/bin/xdg-mime: 848: cannot create /root/.config/mimeapps.list.new: Directory nonexistent xdg-mime default bombadillo.desktop x-scheme-handler/gemini touch: cannot touch '/root/.config/mimeapps.list': No such file or directory /usr/bin/xdg-mime: 848: cannot create /root/.config/mimeapps.list.new: Directory nonexistent xdg-mime default bombadillo.desktop x-scheme-handler/finger touch: cannot touch '/root/.config/mimeapps.list': No such file or directory /usr/bin/xdg-mime: 848: cannot create /root/.config/mimeapps.list.new: Directory nonexistent ``` I'm doing this on Ubuntu 19.10. I'm not sure why this works for you, or maybe it only appears to work for you. I need to research this further, but: - This fails because my `/root` directory does not have a `./config` directory - I don't understand how `xdg-mime` could set my default assosciations by placing files in `/root`, a directory I can't read - The man page says that 'xdg-mime default' should not be run as root, probably for this reason(???), but how are you meant to set a system-wide default? The `--mode` setting only refers to installing and uninstalling, but that's a different thing? I'll do some more reading to try to understand this and let you know what I find out.

asdf commented

2019-11-20 04:10:34 +00:00

I haven't been able to get very far with this.

Adding entries to /usr/share/applications/defaults.list allows registration in (I assume) a system-wide manner. I just appended this:

x-scheme-handler/gopher=bombadillo.desktop
x-scheme-handler/gemini=bombadillo.desktop
x-scheme-handler/finger=bombadillo.desktop

and then xdg-open tries to handle those URIs.

I think there is a "proper" way to do all of this, using xdg-mime install and an XML document. That will take a while to get through.

I haven't been able to get very far with this. Adding entries to `/usr/share/applications/defaults.list` allows registration in (I assume) a system-wide manner. I just appended this: ``` x-scheme-handler/gopher=bombadillo.desktop x-scheme-handler/gemini=bombadillo.desktop x-scheme-handler/finger=bombadillo.desktop ``` and then xdg-open tries to handle those URIs. I think there is a "proper" way to do all of this, using `xdg-mime install` and an [XML document](https://specifications.freedesktop.org/shared-mime-info-spec/latest/ar01s02.html). That will take a while to get through.

sloum commented

2019-11-20 05:13:32 +00:00

Yeah, that is really weird. Mine does not try to install to a folder called root. I wonder if this has to do with some other xdg variable setting on your system?

What happens if you try to run:

xdg-settings set default-url-scheme-handler gopher bombadillo.desktop

That is an alternate way to go about things. It should produce the same result, but maybe will work better.

If you dont get an error, the setting can be confirmed by running:

xdg-settings get default-url-scheme-handler gopher

If you have better luck with this then I am fine with switching over to it.

Either way, if we move forward we should prepend the command with a -. That way if it errors it doesn't halt installation. We can just consider it an optional part of the install. That said, it has made opening gopher/gemini/finger links from firefox really convenient.

If the mime portion of this is deemed to unstable for the makefile I would like to update this branch to remove the mime stuff but keep the desktop file stuff. I think that portion should be very solid. That said, the - prefixing should take care of issues with adding mime and at least it would work on some systems that way. I think it is a really useful feature.

Yeah, that is _really_ weird. Mine does not try to install to a folder called root. I wonder if this has to do with some other xdg variable setting on your system? What happens if you try to run: ```shell xdg-settings set default-url-scheme-handler gopher bombadillo.desktop ``` That is an alternate way to go about things. It should produce the same result, but maybe will work better. If you dont get an error, the setting can be confirmed by running: ```shell xdg-settings get default-url-scheme-handler gopher ``` If you have better luck with this then I am fine with switching over to it. Either way, if we move forward we should prepend the command with a `-`. That way if it errors it doesn't halt installation. We can just consider it an optional part of the install. That said, it has made opening gopher/gemini/finger links from firefox really convenient. If the mime portion of this is deemed to unstable for the makefile I would like to update this branch to remove the mime stuff but keep the desktop file stuff. I think that portion should be very solid. That said, the `-` prefixing should take care of issues with adding mime and at least it would work on some systems that way. I think it is a really useful feature.

sloum commented

2019-11-20 06:05:30 +00:00

Sorry, I had missed your above comment about adding directly to the file. I do believe that, as you mention, it is not recommended :-/

Try the xdg-settings version of the command and see if you have any better luck with that?

I was definitely hoping to avoid having to go the xml route, particularly given that xdg-utils ships with two different ways to make this work. Hopefully we can get sorted through it and not have to resort to the xml (which was what made me shy away from doing it for osx).

Sorry, I had missed your above comment about adding directly to the file. I do believe that, as you mention, it is not recommended :-/ Try the `xdg-settings` version of the command and see if you have any better luck with that? I was definitely hoping to avoid having to go the xml route, particularly given that [xdg-utils](https://wiki.archlinux.org/index.php/Xdg-utils) ships with two different ways to make this work. Hopefully we can get sorted through it and not have to resort to the xml (which was what made me shy away from doing it for osx).

asdf commented

2019-11-20 11:33:04 +00:00

xdg-settings changes my user's mimeapps.list (in ~/.config). Running with sudo returns a similar error to xdg-mime. Reading the man page, it is also not designed to be run as root.

Maybe to clarify a point, when I run these commands as my user it all works. My user can't do make install though, it does not have permissions to the areas being modified.

Also, another point to clarify: the folder root mentioned in the errors is the root user's home directory. Running these commands with sudo is trying to make the same user-specific changes, but to the root user.

It's possible that your root user has a home directory with a .config directory in it. You wouldn't get those errors when running sudo make install if that were the case.

Regardless, I'm not too sure what other options there might be apart from removing it, ignoring the errors, or doing an XML. The xdg-mime commands could be moved to another target, with an additional step saying "if you want to set up URI handlers, run make handlers with your user account".

`xdg-settings` changes my user's mimeapps.list (in ~/.config). Running with sudo returns a similar error to `xdg-mime`. Reading the man page, it is also not designed to be run as root. Maybe to clarify a point, when I run these commands as my user it all works. My user can't do `make install` though, it does not have permissions to the areas being modified. Also, another point to clarify: the folder root mentioned in the errors is the root user's home directory. Running these commands with sudo is trying to make the same user-specific changes, but to the root user. It's possible that your root user has a home directory with a `.config` directory in it. You wouldn't get those errors when running `sudo make install` if that were the case. Regardless, I'm not too sure what other options there might be apart from removing it, ignoring the errors, or doing an XML. The `xdg-mime` commands could be moved to another target, with an additional step saying "if you want to set up URI handlers, run `make handlers` with your user account".

sloum commented

2019-11-20 14:53:49 +00:00

That all still seems weird that I can run it (also on ubuntu) and you cannot. I wonder if this has anything to do with me setting my XDG_CONFIG_HOME to ~? That is the only thing I can think of that would be majorly different. I'm on a pretty standard Ubuntu install. I

Taking the above inconsistencies aside, I would be fine with adding a target I guess. make handlers sounds ok. The only issue with that is it only works for one user and is of no use to sys admins setting up bombadillo for the whole system.

I would also be fine with skipping errors or ditching mime for the time being (but keeping desktop). Let me know what you think the best way would be.

I leave for vacation tomorrow (I'll have my computer with me so will be able to respond to things, but it may be intermittent), so my work day will be pretty lax today. I can try to look into the xml thing and see if that can be a solution for us as well.

That all still seems weird that I can run it (also on ubuntu) and you cannot. I wonder if this has anything to do with me setting my XDG_CONFIG_HOME to `~`? That is the only thing I can think of that would be majorly different. I'm on a pretty standard Ubuntu install. I Taking the above inconsistencies aside, I would be fine with adding a target I guess. `make handlers` sounds ok. The only issue with that is it only works for one user and is of no use to sys admins setting up bombadillo for the whole system. I would also be fine with skipping errors or ditching mime for the time being (but keeping desktop). Let me know what you think the best way would be. I leave for vacation tomorrow (I'll have my computer with me so will be able to respond to things, but it may be intermittent), so my work day will be pretty lax today. I can try to look into the xml thing and see if that can be a solution for us as well.

asdf commented

2019-11-23 00:48:11 +00:00

Just for reference, I'm also testing this on Ubuntu and XDG_CONFIG_HOME variable doesn't seem to have an impact.

There might be a solution using desktop-file-install. I'm reading about it now, but it can run using sudo and installs the desktop file and URI handlers in one go. I'll update with some more information once I have it.

Just for reference, I'm also testing this on Ubuntu and XDG_CONFIG_HOME variable doesn't seem to have an impact. There might be a solution using `desktop-file-install`. I'm reading about it now, but it can run using sudo and installs the desktop file and URI handlers in one go. I'll update with some more information once I have it.

sloum commented

2019-11-23 01:29:18 +00:00

Awesome! This is a great lead. Hopefully it pans out :) Definitely let me know what you find.

asdf commented

2019-11-23 02:56:30 +00:00

I've tested on two systems here and I think this is reliable when either:

Browsing to a link from Firefox
Executing xdg-open URL

It requires package desktop-file-utils which I think is installed by default on Ubuntu even with a minimal install.

The high-level process is:

Install desktop file
Install icon file
Update the desktop database

Step 1 and 2 can be done as we currently do (manually copy files), however the tool install-desktop-file will validate and install the file.

Step 3 can be done using the command update-desktop-database, but if we use desktop-file-install it has a flag to perform this operation.

The tools don't seem to have the ability to uninstall, so we still need to manually remove the desktop file, the icon, and then run update-desktop-database.

These are the two options for installation, first is not using desktop-file-install:

        install -d ${DESTDIR}${DATAROOTDIR}/applications
        install -m 0644 ./bombadillo.desktop ${DESTDIR}${DATAROOTDIR}/applications
        install -d ${DESTDIR}${DATAROOTDIR}/pixmaps
        install -m 0644 ./bombadillo-icon.png ${DESTDIR}${DATAROOTDIR}/pixmaps
        update-desktop-database

and here is how it can be used:

        install -d ${DESTDIR}${DATAROOTDIR}/pixmaps
        install -m 0644 ./bombadillo-icon.png 
        desktop-file-install --dir=${DESTDIR}${DATAROOTDIR}/applications --mode 0644 --rebuild-mime-info-cache ./bombadillo.desktop

Of the two options, the second seems more appropriate because of the validation performed. Considering the uninstall is just deleting the files, the first would be more a more uniform approach and does not require the tool (although maybe the tool is commonly installed like xdg-open?)

By the way, there is a warning on bombadillo.desktop I thought you might like to see:

./bombadillo.desktop: warning: value "Network;Application;WebBrowser;ConsoleOnly;" for key "Categories" in group "Desktop Entry" contains a deprecated value "Application"

I've tested on two systems here and I think this is reliable when either: 1. Browsing to a link from Firefox 2. Executing `xdg-open URL` It requires package *desktop-file-utils* which I think is installed by default on Ubuntu even with a minimal install. The high-level process is: 1. Install desktop file 2. Install icon file 3. Update the desktop database Step 1 and 2 can be done as we currently do (manually copy files), however the tool `install-desktop-file` will validate and install the file. Step 3 can be done using the command `update-desktop-database`, but if we use `desktop-file-install` it has a flag to perform this operation. The tools don't seem to have the ability to uninstall, so we still need to manually remove the desktop file, the icon, and then run `update-desktop-database`. These are the two options for installation, first is not using `desktop-file-install`: ```make install -d ${DESTDIR}${DATAROOTDIR}/applications install -m 0644 ./bombadillo.desktop ${DESTDIR}${DATAROOTDIR}/applications install -d ${DESTDIR}${DATAROOTDIR}/pixmaps install -m 0644 ./bombadillo-icon.png ${DESTDIR}${DATAROOTDIR}/pixmaps update-desktop-database ``` and here is how it can be used: ```make install -d ${DESTDIR}${DATAROOTDIR}/pixmaps install -m 0644 ./bombadillo-icon.png desktop-file-install --dir=${DESTDIR}${DATAROOTDIR}/applications --mode 0644 --rebuild-mime-info-cache ./bombadillo.desktop ``` Of the two options, the second seems more appropriate because of the validation performed. Considering the uninstall is just deleting the files, the first would be more a more uniform approach and does not require the tool (although maybe the tool is commonly installed like `xdg-open`?) By the way, there is a warning on `bombadillo.desktop` I thought you might like to see: ```shell ./bombadillo.desktop: warning: value "Network;Application;WebBrowser;ConsoleOnly;" for key "Categories" in group "Desktop Entry" contains a deprecated value "Application" ```

sloum commented

2019-11-23 04:21:31 +00:00

I'm on really spotty internet so testing this on remote servers has been tricky. Hopefully this message sends.

It does not look like Arch (at least the Arch running on rawtext) has desktop-file-install installed (nor update-desktop-database). But that may be because it is not configured for a graphical environment.

I had notcied that error just before you sent this last message! Just pushed it.

I think the first approach appeals more to me. The reason is that if either update-desktop-database or desktop-file-install are not present on the system, the desktop file is still where it needs to be.

As such, my vote is for:

install -d ${DESTDIR}${DATAROOTDIR}/applications
install -m 0644 ./bombadillo.desktop ${DESTDIR}${DATAROOTDIR}/applications
install -d ${DESTDIR}${DATAROOTDIR}/pixmaps
install -m 0644 ./bombadillo-icon.png ${DESTDIR}${DATAROOTDIR}/pixmaps
-update-desktop-database

(Note the dash before update-desktop-database)

I do agree that the validation is very useful, but it is something we can run before release. I'm not sure we gain a lot by having the user run it on install (so long as we have done so prior).

Let me know if you agree. If not I'm definitely open to pursuing other options if we can find a good one (or if you think desktop-file-install is the way to go)...

I'm on really spotty internet so testing this on remote servers has been tricky. Hopefully this message sends. It does not look like Arch (at least the Arch running on rawtext) has `desktop-file-install` installed (nor `update-desktop-database`). But that may be because it is not configured for a graphical environment. I had notcied that error just before you sent this last message! Just pushed it. I think the first approach appeals more to me. The reason is that if either update-`desktop-database` or `desktop-file-install` are not present on the system, the desktop file is still where it needs to be. As such, my vote is for: ``` install -d ${DESTDIR}${DATAROOTDIR}/applications install -m 0644 ./bombadillo.desktop ${DESTDIR}${DATAROOTDIR}/applications install -d ${DESTDIR}${DATAROOTDIR}/pixmaps install -m 0644 ./bombadillo-icon.png ${DESTDIR}${DATAROOTDIR}/pixmaps -update-desktop-database ``` (Note the dash before `update-desktop-database`) I do agree that the validation is very useful, but it is something we can run before release. I'm not sure we gain a lot by having the user run it on install (so long as we have done so prior). Let me know if you agree. If not I'm definitely open to pursuing other options if we can find a good one (or if you think `desktop-file-install` is the way to go)...

asdf commented

2019-11-23 22:25:22 +00:00

Ok I've updated this now, I think it's ready for merging in. I did add piping of errors to /dev/null for update-desktop-database, although does this negate the use of -?

A point on your investigation: RTC will likely not have desktop-file-utils package as it does not seem to have any desktop packages installed (for example, xdg-open is also not available). There is an arch package for this software though.

Finally, a note on the makefile itself: it serves a fairly general purpose now, and further improvements have a couple of competing demands:

we want to add new functionality and validate it to ensure a good experience
there is a point where it may be less effort, and more reliable, to learn and use autotools (or another build system, (edit:or just package the application)
we don't want to overcook it, and do either of these things without some meaningful demand

Ok I've updated this now, I think it's ready for merging in. I did add piping of errors to /dev/null for `update-desktop-database`, although does this negate the use of `-`? A point on your investigation: RTC will likely not have `desktop-file-utils` package as it does not seem to have any desktop packages installed (for example, `xdg-open` is also not available). There is an arch package for this software though. Finally, a note on the makefile itself: it serves a fairly general purpose now, and further improvements have a couple of competing demands: - we want to add new functionality and validate it to ensure a good experience - there is a point where it may be less effort, and more reliable, to learn and use autotools (or another build system, (edit:or just package the application) - we don't want to overcook it, and do either of these things without some meaningful demand

sloum commented

2019-11-24 05:29:17 +00:00

The updates look good to me. I'm not sure what happens with a pipe to null and the - operator in a makefile. I think it should still work fine. The process would still not exit with 0 so the dash is needed to continue execution. I think it should be good.

That makes sense for RTC.

Agreed. There is a fine line between providing something useful and featureful and giving people too much and making it difficult for them to do it the way that makes sense on their system. I would still like to package the program at some point for at least debian (and derivatives). Maintaining multiple versions for multiple distros could quickly become a pain, but I am at least mildly interested in trying it out with one (to start with). In a perfect world the code would be developed here and there would be a maintainer for each distro that handled packaging the application. Maybe if this release takes off there might be some interest at some point.

I do not know much about autotools. It could be interesting to try it out. I had been under the impressions that they were mostly used for C/C++ code, but maybe that is a misconception? I have not used other build systems at all. Maybe once the release is up I can spend a little bit of time reading up on build systems and get some pros/cons together and see if it would make sense to change things up for the following release or not.

I'm going to merge this in. This should be the last code push! Just docs from here until release (hopefully, lol).

The updates look good to me. I'm not sure what happens with a pipe to null and the `-` operator in a makefile. I think it should still work fine. The process would still not exit with 0 so the dash is needed to continue execution. I think it should be good. That makes sense for RTC. Agreed. There is a fine line between providing something useful and featureful and giving people too much and making it difficult for them to do it the way that makes sense on their system. I would still like to package the program at some point for at least debian (and derivatives). Maintaining multiple versions for multiple distros could quickly become a pain, but I am at least mildly interested in trying it out with one (to start with). In a perfect world the code would be developed here and there would be a maintainer for each distro that handled packaging the application. Maybe if this release takes off there might be some interest at some point. I do not know much about autotools. It could be interesting to try it out. I had been under the impressions that they were mostly used for C/C++ code, but maybe that is a misconception? I have not used other build systems at all. Maybe once the release is up I can spend a little bit of time reading up on build systems and get some pros/cons together and see if it would make sense to change things up for the following release or not. I'm going to merge this in. This should be the last code push! Just docs from here until release (hopefully, lol).

sloum closed this pull request

2019-11-24 05:29:25 +00:00

sloum deleted branch desktop-file

2019-11-24 05:29:34 +00:00

Sign in to join this conversation.

No reviewers