However, since you haven't yet provided any details about how you built with Qt (Qt isn't officially supported, so you must have used a third party derivative of vim), and you haven't provided any detailed information about what error messages or malfunctions you're having with python-complete, it's not really possible to tell you how to fix the problem and get vim working with Qt.

It would be very nice if that was consistent across every application.

The issue is kind of regression/trade-off for keep bundles get loaded same as the declaration order. The only thing this part added is the new BundleBind! command. Sure we should try fix issue by not introduce new feature/concept as possible as we can, but when the concept/complexity is just add a simple command without any argments to the configuration, and the benefit is clean, simple and efficient implementation, IMHO it is worth. That's why I finally chose this solution.

Here are my thoughts: making vim startup time shorter is GOOD added complexity - BAD my main concern is with the complexity that gets added to get startup time improvements. User has to tag scripts, and then manually BundleBind to get scripts loaded. This seems like too much hassle(manual involvement) to me. Fixing 1 time thing (startup) we're adding many more (like BundleBinding required scripts once they're used) For instance in my case i don't start Vim often because i'm using --remote-tab-silent option. So i'll get no benefit along with complexity (

It is critical you put better_errors only in the development section of your Gemfile. Do NOT run better_errors in production, or on Internet-facing hosts.

awk is my weapon of choice when it comes to text processing. Besides, it's syntax is close to C

$(awk -F= '/^Exec/||/^TryExec/ {print $2;exit}' /usr/share/applications/firefox.desktop)

If still doesn't work. Make desktop file runnable in terminal by changing Terminal=true, and put it inside a bash script. Run the script to catch the error output. Change back when errors are corrected.

you can use "${@:1}" instead of shift, but that requires bash instead of sh in your #! shebang. IMHO your original shift approach is simpler and better

Now, if you also want deskopen to pass through any command-line parameters, you can instead use this slightly-modified version: #!/bin/sh desktop_file=$1 shift `grep '^Exec' "${desktop_file}" | sed 's/^Exec=//' | sed 's/%.//'` "$@" &

Given the deskopen script, you can use a reference to it as the shebang line in a .desktop file

The "correct" way to install a .desktop file is via desktop-file-install

This is the only answer that does not require manually parsing the .desktop file, so it's the most sane (and safe) approach.

It will be useless work when gvfs-open will solve the bug, but in the meantime...

this is so stupid (that there is no sensible way to run a Desktop file from the terminal)

gtk-launch <app-name> - where <app-name> is the file name of the .desktop file, with or without the .desktop extension.

If I do gnome-open foo.desktop it simply opens foo.desktop as a text file. If I make it executable and then run it in bash it simply fails (which is expected, it's clearly not bash script). EDIT: Doing exec /fullpath/foo.desktop gives me a Permission denied message, even if I change ownership to myself. If I make executable and do the same command, the terminal tab I'm using simply closes (I'm guessing it crashes). Finally, if I do sudo exec /fullpath/foo.desktop, I get an error reporting sudo: exec: command not found.

I find it convenient to change proxy and other settings through gui window by right-clicking on launcher icon on my desktop. I mostly start slack by clicking desktop launcher, but also want to be able to start it from command line in some cases.

(xdg-open seems to be supposed to be the universal one...)

If you really want this, I suggest you write a little function that extracts the executable name from the .desktop file and runs it. Add these lines to your shell's initialization file (e.g. ~/.bashrc): runDesktop () { eval "$(awk -F= '$1=="Exec"{$1=""; print}' "$1")" } Then, you can run your .desktop file with runDesktop ~/Desktop/slack.desktop

We could add heuristics like: is the file inside XDG_DATA_DIRS/applications? if not, is the file inside XDG_DATA_HOME/applications? if not, is the file marked as executable? if not, open with the text editor

Sorry you’re surprised. Issues are filed at about a rate of 1 per day against GLib. Merge requests at a rate of about 1 per 2 days. Each issue or merge request takes a minimum of about 30 minutes (across at least 2 people) to analyse, put together a fix, test it, review it, fix it, review it and merge it. I’d estimate the average is closer to 3 hours than 30 minutes. Even at the fastest rate, it would take 3 working months to clear the backlog of ~1000 issues. I get a small proportion of my working time to spend on GLib (not full time).

Age of a ticket is completely irrelevant as anyone can request anything but the number of developers is limited. If you'd like to see something implemented, please consider providing a patch. Thanks!

Sorry if I sounded rude. I am using Gnome on a daily basis and am highly appreciating all the work anyone has put into it. I was just surprised when I found an AskUbuntu post from 2010 linking to this bug.

Wow 14 years. I still keep stumbling over this issue...

This issue hasn’t been deemed a high enough priority to be fixed yet. It will be addressed one day, I’m sure. There are many issues in GLib which many people on the internet think are important.

Hello , since I made a modification in gio-tool (#2098 (closed)) , I seen this issue and decide to give it go. I implemented an unix only solution only for launching a desktop file through gio command, see !1779 (merged)

In the meantime, people do seem to appreciate a developer spending 2 minutes to reply to comments on old issues, just so they’re not ignored and to manage expectations.

When one is searching for it on the internet, there are many many people wondering how one can open .desktop files. It seems trivial, since one usually just has to click an item on the launcher so one thinks there must be some way.

I am wondering if it wasn't faster for maintainers/developers who know the glib code to just provide a fix instead of writing comments on this issue.

It sounds like a gnome-open (or the equivalent library call) bug. Reassigning.

I agree that it's bad to have to handle this at the application level

I have to agree with Raphael here that this should probably be handled in gnome-open, its a pain to have to implement .desktop parsing code in every beagle front end when I can't really think of an instance where the expected behavior wouldn't be to execute the associated command.

I don't know what nautilus does, but i think when you double click a .desktop file it launches the associated program, i guess they don't use gnome-open then..

deskbar should probably detect their extension and execute the relevant command as opposed to opening the file for editing.

Thanks for your contribution!

The commit message should always have some explanation, see https://wiki.gnome.org/Git/CommitMessages.

The following steps will help you to get to a working systemd/user configuration:

I consider systemd/user as a good alternative for dex's autostart functionality and switched to it recently. In particular, systemd solves the issue of dex losing control over the started processes which causes processes to live longer than the X session which could cause additional annoyances like reboots taking a lot of time because the system is waiting for the processes to terminate.

Is somehow possible to run a "Desktop Entry" from another "Desktop Entry"?

The reason we've avoided registering "Cinnamon" as a desktop name is that it opens up issues with many upstream apps that currently OnlyShowIn=Gnome or Gnome;Unity or just Unity. The relationship Mint has with Gnome and Ubuntu isn't genial enough that we could get them to add Cinnamon to their desktop files, so we would have to distribute and maintain separate duplicate .desktop files just for Cinnamon for these upstream packages.

You're right, it would solve the Nemo problem perfectly, but break a lot of other things, unfortunately.

Also manually adding [Default Applications] x-scheme-handler/zoommtg=ZoomLauncher.desktop to either $HOME/.config/mimeapps.list or $HOME/.local/share/applications/mimeapps.list does not lead to xdg-open via exo-open recognizing the zoommtg protocol.

After you modify mimeapps.list, run sudo update-desktop-database.

A solution is almost indicated in the question: hinder xdg-open from choosing exo-open. A brute-force approach is to copy /usr/bin/xdg-open to /usr/local/bin (/usr/local/bin is earlier in PATH unless PATH has been modified) and to patch it to use open_generic instead of exo_open (unlike the XFCE4-specific exo-open, open_generic does honor xdg mime types)

Does running nsgcepa by itself not then run the .desktop which in turn runs that command? Probably not. Desktop launchers are used by e.g. application menus. Executables are the binaries or scripts that can be run by desktop launchers. You can also run executables directly from a command line.

Does running nsgcepa by itself not then run the .desktop which in turn runs that command?

Firstly, it's nice to see a well-structured question post!

I don't use remote editing much so vim-dirvish is powerful enough to manage my workflow (It's actually faster than netrw ~ the author claims 2x, I feel it's faster than that - it's really instantaneous ⚡) very useful on large codebase/repositories

I was searching for a solution to this problem too since I actually removed netrw from being loaded in vim completely and replace it with vim-dirvish. This plugin has around 500~ LOC, compared to netrw's (11,000+ LOC).

when the link of accessing a workspace appear I only get the popup: "Open xdg-open?" and then nothing happens.

neither knows what to do with naked domain. So gnome-open http://askubuntu.com works but not gnome-open askubuntu.com. Here is a small function to make it easier to type and accept the stripped down domain name. function go { gnome-open http://$1 ; }

xdg-email

xdg-mime query default text/html To find out what application is going to be used

There's a command that knows about your default browser: xdg-open http://google.com This will also work for every other type of URI (Uniform Resource Identifier), like images - which will automatically open with eog, openoffice documents, and so on, and also on filesystem paths (xdg-open /tmp/foobar.png).

Here is a link to install a deb version of chromium, seems like it be easier to use another browser myself.

Not sure but might be a chromium snap problem. Snaps have very few permissions, can try going to software centre/store and see if you can give more permissions, should just be on/off switch, or might need to use another browser(deb not snap). Chromium might have a deb only version now again, but not sure if for 19.10 or only 20.04.

xdg-mime query default x-scheme-handler/magnet

xdg-open should do the same thing - actually, it will call gnome-open, or kde-open, or whatever, depending on your desktop environment. Thus it's more portable.

The advantage is that you can use gnome-open for almost all file-types, URIs and directories. It's one command to learn, instead of trying to remember about obscure commands like sensible-browser

XDG stands for X Desktop Group aka freedesktop.org

what does xdg stand for? Its hard to remember without knowing that.

Works also on Linux if you install Steam for Windows on Wine.

Poetry is more than end rhymes

Support for most major platforms (Windows, Mac, Linux, SteamOS)

When you're didactic, you're trying to teach something. Just about everything teachers do is didactic: the same is true of coaches and mentors.

This word is often used negatively for when someone is acting too much like a teacher.

Note that autosave will only trigger for already-persisted association records if the records themselves have been changed. This is to protect against SystemStackError caused by circular association validations.

Honestly the critic reviews entire miss the point of this game. The game is a tongue-in-cheek love letter to Japanese quirk/kitsch. The controls are intentionally awkward. The physics are intentionally always just that little bit unpredictable. Watch a few gameplay trailers to get a far more accurate depiction of the chaos that is Nippon Marathon that I ever got from any of the ‘professional’ critic reviews.

Tbh I find the 44 critic metascore really appalling so made an account just to leave this review.

This games a scam. Reviews are fake.

Based on my search, the game might be developed by neptun digital, an Android game called Brain On Physics Drop - Idle Balls Puzzle. It was released on Amazon, on June 29, 2017. Free.Later on Sep 4, 2017 it was put on google play store called Physics Brain Balls - Drop It On Dots. Free.Then in June 2018, its web browser version Love Draw released by Faramel Games. Free.Later here on Jan 9, 2019, Windows port showed up. Paid to play. Apart from all of this, the design of origin is simply modified based on a free game called Brain Dots released in 2015.A port doesn't deserve to be paid, let alone the origin of the port is not original at all.

A simple, yet surprisingly mind-boggling puzzle game. Simplicity may be perceived as a negative connotation when it comes to games for many people, but Neon Warp's simplicity actually works in it's favor in the best way possible and becomes one of it's strength.

LuftWaffel

Game for stuffing achievements

infringing on Marvel's copyrights

First off, achievement spam is not a selling point. In fact, this game broke my Steam client because it spams achievements. Whenever I closed it, it froze my client. What am I gonna do with there cheevos anyway? "Look, I got the achievement "Web 1720", am I cool now?"

This content is not compatible on this device.

I get this itch.io message when I try to buy it, "Due to processing fees the minimum amount is 100 cents."

Tried to buy keyg at its 90% off sales price but no matter what payment method I choose I keep getting a "Due to processing fees the minimum amount is 100 cents."I'm trying to figure out if there is any way around this, and if not then why can you list a game at a price below $1 if it isn't actually possible for it to be bought at said price?

Default Values

Dry::Types::Undefined

READ the EDIT on the OP before making snide comments. Also, if you get “like a hundred of these a day” maybe somebody should clearly, I said CLEARLY, label the subreddit as employees only. This vitriol for accidentally wandering into a subreddit that would, to most thinking people, appear to be for customers AND employees to discuss the store is ridiculous.BTW, I’ll take everything I’ve said back and apologize and even make a post calling myself an illiterate imbecile if somebody can point me to where it CLEARLY says “employees only” in either the sidebar, subreddit rules, or the post list. The sticky doesn’t count, it is not worded clearly, it just reads as if you don’t want complaints, not “no customers”.

We are just as in the dark as the customers. We clock in and look at a screen on a scanner and scan the stuff the systems tells us to pick for you. We have no clue how the website worked for you for that order, no clue about billing issues, nada. The system didnt want you to have that item that day. The only thing we can suggest is "try again later". or call 1800walmart and complain to a call taker to see if they can put in a complaint for you. We are peons and know not much more than if you walked in the backroom threw on a vest and did the work yourself. Were not privy to anything and the company doesnt tell us jack shit except how to do the immediate task in front of us until we clock out

Or even a simple 1-liner in the Contract that references an AR Model so you don't have to rewrite the validations again in that contract, or have to choose between writing the validations once either in the contract there or in the AR Model?

Don't let the highly rated reviews fool you, this is one of the worst Steam games I've personally bought and played in years (as of writing this I'm closing in on 4000 games in my Steam library).

Dole Mandarin Oranges in Light Syrup, All Natural Fruit, Non-GMO, 15oz CanNot available for curbside

Third configurable block to run.

Last configurable block to run. Called after frameworks initialize.

A major update usually means breaking changes in the API therefore a bit of learning is required in order to embrace it in your projects.

Trying to force this one thing to work for everyone is the worst way to do that.

If the only realistic consumer of a package is the monorepo, and you can’t realistically see normal users installing that 1 package out of 138 other packages in that repository, there’s probably no need to have it as a separate package. Ideally it would be better to let a user install 1 package that contains everything, and reduce the overhead.

become more obscure in functionality to the point where some names literally describe what they do

It’s an incredibly amount of overhead and waste. Packages increasingly consume more hard drive space, increase installation times

When you look inside a node_modules directory, there’s likely hundreds if not thousands of packages, even for a relatively basic application.

Very often in these monorepos, packages are so incredibly specific in functionality, the question then becomes why even have a separate package at all if it’s tightly coupled? Can you use these packages independently or are they tied to specific versions of other packages in the monorepo? It’ll probably be easier to remove the mask and just work as a monolith.

After all, that’s why it’s in one repository to begin with right?

There’s typically a complex tree of dependencies, where packages all tend to rely on each other in order to function.

However, if all of these are hosted in the same repository, you lose a lot of those benefits.

parallelise development across multiple teams

There’s several benefits to splitting code into multiple packages, whether it be a library, micro-services or micro-frontends.

The criticism of small modules is a bit ironic because it runs deeper than many realize.

But I believe the core philosophy of tiny modules is actually sound and easier to maintain than giant frameworks.

This isn't to say that on a case by case basis there aren't modules that are grossly overcomplicated.

I wanted to examine this criticism because I don't agree with it.

Isaac then continues on to compare that philosophy to Node.js. They are slightly less succinct but still very enlightening.

he goes on to talk about third party problems and how you're never guaranteed something is written correctly or that even if it is you don't know if it's the most optimal solution

he goes on to say that simple functions should not be packages because they are too small.

"Functions Are Not Packages" - Well why not?

He says that writing the function yourself makes it easy to modify and to fix bugs or improve efficiency.

so you can learn about the ones you don't.

Write modules that solve a problem you know

By treating even small functions like a black box it promotes separation of concerns and allows said black box to evolve independently.

I would much rather have a "cosine" module than a "trigonometry" module because chances are good I only need a small fraction of the utilities provided by the larger trig module.

I found this bit a tad ironic considering he's simultaneously admonishing small modules while complaining about how difficult it is to debug other people's code.

Write modules quickly, to meet your needs, with just a few tests for compliance. Avoid extensive specifications.

Write modules for publication, even if you only use them privately. You will appreciate documentation in the future.

Of course how each developer interprets and applies these very generalized guidelines is subjective and will vary from person to person.

For one, anyone using this module would automatically benefit from any future performance improvements without having to do anything themselves.

Small modules are extremely versatile and easy to compose together in an app with any number of other modules that suit your needs.

Refactor ruthlessly. Rewrite bravely.

Write modules that are small. Iterate quickly.

Write modules that are agnostic about the source of their input or the destination of their output.

Write modules that do one thing well. Write a new module rather than complicate an old one.

Write modules that encourage composition rather than extension.

Sure sometimes my changes get rejected, but it almost always comes with a reason why and I can work together with the maintainer to come up with a sensible solution to my issue.

Second, I don't agree that there are too many small modules. In fact, I wish every common function existed as its own module. Even the maintainers of utility libraries like Underscore and Lodash have realized the benefits of modularity and allowed you to install individual utilities from their library as separate modules. From where I sit that seems like a smart move. Why should I import the entirety of Underscore just to use one function? Instead I'd rather see more "function suites" where a bunch of utilities are all published separately but under a namespace or some kind of common name prefix to make them easier to find. The way Underscore and Lodash have approached this issue is perfect. It gives consumers of their packages options and flexibility while still letting people like Dave import the whole entire library if that's what they really want to do.

You might get the impression after reading David's article above that this trend arose from lazy developers who "forgot how to program", but the reality is that the tiny-module ecosystem on NPM was the intention from the beginning

Start by asking these 9 Big Life Questions:

Hasty generalization usually follows the pattern:

Hasty generalization is the fallacy of examining just one or very few examples or studying a single case, and generalizing that to be representative of the whole class of objects or phenomena.

the Unix Philosophy is a crucial part of the patterns, opinions, and culture of Node.js

All too often, people get hung up on the wrong aspects of the Unix Philosophy, and miss the forest for the trees

Those sorts of complaints are like saying that someone is not a buddhist unless they speak Pali.

In the real world, we are faced with the completely unfair constraint of being human while writing programs and while debugging them, and none of these costs can ever be reduced to zero.

Simplicity is better than anything.

Compatibility is better than purity.

Focus is better than features.

Working is better than perfect.

It is about balancing the twin needs of writing good software, and writing any software at all.

It’s a practical set of advice for trading a moderate increase in development cost for a much larger reduction in maintenance costs.

Nothing about the Unix Philosophy explicitly relates to a culture of software sharing. However, it should be no mystery that it comes from the software community where we argue at length about the best way to make our programs properly Free. Software that is developed according to these principles is easier to share, reuse, repurpose, and maintain.

The Unix Philosophy is an ideology of pragmatism.

There's a joke in philosophy that goes like this: The First Law of Philosophy: For every philosopher, there exists an equal and opposite philosopher. The Second Law of Philosophy: They're both wrong.

Let's define idealism as a rigid belief system in which you live your life based upon a morality as it is "supposed to be" or "should be,"

let's define pragmatism as doing what is practical, regardless of how you things are supposed to be or should be

An ideology (/ˌʌɪdɪˈɒlədʒi/) is a set of beliefs or philosophies attributed to a person or group of persons

more recent use treats the term as mainly condemnatory

The customer overspecified the requirements and now we're contractually required to build it this way. Does he think he's an engineer?

To specify in excessive detail.

Why separate out red tests from green tests? Because my green tests serve a fundamentally different purpose. They are there to act as a living specification, validating that the behaviors work as expected. Regardless of whether they are implemented in a unit testing framework or an acceptance testing framework, they are in essence acceptance tests because they’re based upon validating behaviors or acceptance criteria rather than implementation details.

When I refactor my code, I expect that none of my green tests will break. If red tests break then that’s okay because remember, my red tests can be implementation dependent and when I change an implementation it may cause some red tests to break. But it shouldn’t break any green tests. I find that this is a valuable distinction.

Conversely, red tests are tests I write after the code is written to lock down some implementation.

Have you ever played the game 20 questions? Most of us have played that game at one point in our lives. One person thinks of something that could be an animal, vegetable, or mineral and then they answer yes/no questions that are asked of them. The point of the game is to ask as few questions as possible in order to accurately guess what the person is thinking.  This is how I think of the unit tests that I write the specified behavior as I’m doing test-first development. I ask what are the fewest tests that I need to write in order to assert the behavior I want to create.

So the question becomes how many tests are enough?

I’m proposing that writing those tests from the perspective of specifying the behaviors that we want to create is a highly valuable way of writing tests because it drives us to think at the right level of abstraction for creating behavioral tests and that allow us the freedom to refactor our code without breaking it

I am a big advocate of having a complete test base and even erring on the side of caution when it comes to quality engineering and software validation but that is not what we’re talking about here. What we’re talking about here are the tests that we write when we’re doing test-first development and I’m proposing that writing those tests from the perspective of specifying the behaviors that we want to create is a highly valuable way of writing tests because it drives us to think at the right level of abstraction for creating behavioral tests and that allow us the freedom to refactor our code without breaking it.

The number one problem that I see developers have when practicing test-first development that impedes them from refactoring their code is that they over-specify behavior in their tests. This leads developers to write more tests than are needed, which can become a burden when refactoring code.

Sometimes a change impact analysis is performed to determine an appropriate subset of tests

non-regression testing

Regression testing (rarely non-regression testing[1]) is re-running functional and non-functional tests to ensure that previously developed and tested software still performs after a change.[2] If not, that would be called a regression.

We respect client confidentiality

The granularity of data refers to the size in which data fields are sub-divided