Ulauncher showed up with thick black border

Created on 6 Feb 2018  路  42Comments  路  Source: Ulauncher/Ulauncher


When auto started, ULauncher shows up with a thick black border.

Steps to reproduce:

  1. Install ULauncher
  2. Select "Launch At Login" from Preferences.
  3. Logout & login again.
  4. Press Ctrl + Enter

Ulauncher version: 4.0.6.r1
Linux distro: Linux Mint 18.3 Sylvia 64 Bit
Desktop environment: KDE

screenshot_20180206_121053

bug severity-low

Most helpful comment

Still remains on Bspwm (Archlinux) without compositor. :cry:

All 42 comments

Looks similar to #211

This bug usually occurs when compositor is disabled (see this comment)

I'll try to reproduce it myself with the specified OS and DE, and if issues like this occur with a default setup (w/o modifications to an installed os) this needs to be fixed in Ulauncher somehow.

I checked in KDE settings. "Enable compositor on startup" is checked. That means compositor is running. I think it can be a situation where Ulauncher starts before the compositor starts up after login. If Ulauncher assure starting after host OS compositor startup then it may solve the issue.

If Ulauncher assure starting after host OS compositor startup then it may solve the issue.

Does that actually fix the issue for you?

p.s. My laptop got broken. I haven't yet looked into this. Will try to reproduce this issue sometime next week.

@ayanb1991 I checked in KDE settings. "Enable compositor on startup" is checked. That means compositor is running. I think it can be a situation where Ulauncher starts before the compositor starts up after login. If Ulauncher assure starting after host OS compositor startup then it may solve the issue.

I think that should be the case because I do not get the thick black border when I start Ulauncher for the second time. My environment is on Xubuntu 16.04.

@erayerdin @gornostal Yup when I exit ULauncher and start it manually after login, the black border does not appear. Both in KDE & XFCE. I have tested it many times. It always happens when ULauncher auto starts after login.

Now, for those who want a quick dirty fix...

Since the issue happens when Ulauncher starts while desktop environment is loading, the trick is to get it started after a couple of seconds. So, I've written a bash script called launch-ulauncher as below:

#!/usr/bin/env bash

# You can tweak here.
sleep 15
ulauncher

I've put it under /opt/scripts. This is where I put my scripts and it is also in path variable. Where you put this script is not important but you need to know where it is. You also need to give executable permission to the script:

chmod +x launch-ulauncher

And then, open startup settings (wherever it is under in your desktop environment) and add the script to launch in the start. If you also have ulauncher in the startup settings, remove it (we don't want multiple instances running). In my case, it is like this under Xubuntu:

image

image

Process should be similar with other desktop environments. This is the trick that worked for me until this issue is resolved.

The script will wait 15 seconds before it will have launched ulauncher. You can tweak this according to your system.

same problem faced in ubuntu 16.04.3 LTS :-1:

@gornostal seems like this black border added because app uses shadow. Maybe you can add an option in settings to disable such shadow because many people use i3 or similiar WM without any compositor running. So it will impossible to hide the border in that situation.
P.S. 携 芯写懈薪 懈蟹 褌邪泻懈褏 谢褞写械泄 懈 褝褌邪 褎懈褔邪 斜褍写械褌 芯褔械薪褜 锌芯谢械蟹薪邪 :)

@avently could you try overriding shadow in custom color theme? box-shadow: none should work I believe.

@gornostal I tried it. Shadow disappeared with compositor, yes, but black border did not without compositor. So without compositor it does nothing

I was able to reproduce and fix the issue.
Issue occurs when compositor starts after Ulauncher.
Guys, could you try v4.0.7.r4 (Dev) and if it works for you I'll add the fix to a stable release?

@gornostal should this fix also work for systems without compositor? If yes, for me it doesn't work without compositor. Black border still here.

should this fix also work for systems without compositor?

@avently not, it should not.

@gornostal ok, i can confirm the fix work when system has compositor.
I tried to make it work without compositor but i couldn't find any piece of code that changed the behaviour of that black frame. Maybe you know what can help in my situation? Why that black space exists? No margins, no padding...

If you look at UlauncherWindow.ui you'll see that GtkBox "body" has 20px margins.
They are needed to make a room for window shadows.

If you want to make the black border disappear, you should either remove the margins or in WindowHelper.py remove self.set_visual(visual), or both. But I'm not sure about that.

Anyway, I don't want to add support for non-compositor environments because it will definitely require implementing workarounds. I'd rather keep the source code as clean as possible.

@gornostal got it. So could you, please, add this line to UlauncherWindow.ui in <object class="GtkBox" id="body"> block:

<style>
   <class name="body"/>
</style>

This will make possible to override margin values in user's theme like this:

.body {
    margin: -20px;
}

And black frame will disapeared. Could you?

Does that work for you?
I guess I tried something like that but it would not work for me.

Yep. I did it and it works. No frame. Didn't get any issues for now
Maybe you tried margin without minus. So margin:0 will not work. Only margin:-20px;. Strange, yes.

I'll add a task to implement that to my list, but that's not a priority. JSYK.
Created a separate ticket for that #230

Thanks for testing the build, btw.
I'm going to make a stable release over the weekends.

@gornostal not a PRIORITY to add 3 lines of code that do nothing bad? Oh, that's so funny. You made my day.

@avently haha :)

In the best case scenario I need about one hour to make that fix and then do a release.
Because I must test it in 3-5 Virtual Boxes, and then manually do a release (my automation got broken because of Travis CI I guess)

But I don't think that fix will work for both GTK+ 3.18 and 3.22. So that's why I'm skeptical about simplicity of the fix. I think it may require more work.

The fix was released with Ulauncher v4.0.7.r5
https://github.com/Ulauncher/Ulauncher/releases/tag/4.0.7.r5

Please reopen if needed.

Yeah! Updated and tested on same platform and the issue is gone. Thanks.

Still remains on Bspwm (Archlinux) without compositor. :cry:

@theFool32 Ulauncher doesn't work without compositor. Could you install it and try running Ulauncher again?

Can confirm that the .body { margin: -20px; } fix works without a compositor.
But there should still definitely be an option to disable border/transparency for older systems.

I'll reopen the bug. If enough people give it a :+1: it will be fixed sooner.
I would not want to add more complexity to the code to fix the issue for very few people.

I would not want to add more complexity to the code

Isn't it simple? 1 line of CSS roughly does the trick for me, so I guess that'd be a good start over the black border.

Anyway, thanks for reopening! I hope this gets fixed because I don't like having a compositor...

I would not want to add more complexity to the code to fix the issue for very few people.

I don't want to be rude but maybe there isn't a lot of users because they've switched to an other software that works out-of-the-box (e.g Rofi).

This type of comment is why Linux users have a bad rep ^ If you think this software which is developed for free is inferior to another piece of software, then great! Use the other software.

@friday oh, don't say this. Because it's only in your head.
Just take a look at comments in google play and after that try to not change your mind.

This type of comment is why Linux users have a bad rep ^ If you think this software which is developed for free is inferior to another piece of software, then great! Use the other software.

@friday It wasn't a insult but simply an observation for why there's maybe not a lot of users who upvote this issue. You're definitely the one being rude here. Maybe next time, try asking people instead of implying what they meant.

Google play is a place where you rate things and write reviews @avently. This is an issue tracker where you're talking to the author and giving info helping him decide how and what to prioritize next. I understand if you don't think this issue have received the attention you wanted it to though. You've been patient and helpful, and I hope this issue will be resolved for you.

I never used the word insult or rude @dannycolin. You're playing rhetorical games you can't handle. You're the one implying things. Like for example how people are leaving to a similar app catering to a different niche, because not having this particular issue means it works out-of-the-box. The other app of course doesn't have issues, weaknesses and limitations right?

Anyone who used both knows working out-of-the-box isn't Rofi's strength. You have to learn how to use it and configure it for it to be useful. Definitely not as easy to use as Ulauncher. I tried Rofi before I even heard about Ulauncher, but went back to Albert (other launcher) because I wasn't able to configure it to work the way I wanted and the author marked an issue preventing that as wontfix. Ulauncher on the other hand already worked as I wanted.

@friday I moved from Albert to ULauncher because of Albert's issues that the author can't (and don't want to) fix. I then moved to Rofi because of this issue and author's reaction on the provided fix.
So, yes, it does matter how app works out-of-the box. You can love this idea or hate it but this is how things work. I'm a developer too and I understand that if my app will be too complex or buggy, users will just leave it. This information should be used to make the app better instead of blaming the users about their bad behavior.

@avently

So, yes, it does matter how app works out-of-the box

Of course it does. No one said otherwise. Authors reactions/attitudes and time allotted to maintain software also matters. Please stop making counter-arguments to arguments no one made.

This information should be used to make the app better

Really? So you don't think people working on free open source software with no funding has the right to prioritize the limited time they have for it? If I report an issue it's the developers duty to fix it even if there are more pressing issues or work or family gets in the way?

I agree satisfying users (especially the ones trying to help like you did) should be the goal though.

instead of blaming the users about their bad behavior

No one is blaming users for bad behavior because they're providing information or have opinions. You provided informations and Danny wrote a very non-constructive comment. You are two different people, and me and Gornostal are two different people.

Arguing about this won't help anyone btw. The issue was left open and you were given an option to use thumbs up to show it affects you. It's not closed or wontfixed. Gornostal just made a blanket statement about not wanting to add more complexity.

This talk is counter-productive.
Danny gave the feedback, you said Linux users have bad reputation.
Nothing to talk about.

please stop.

the chances of getting the developer to care about people without a compositor were slim enough already.

Danny wrote a very non-constructive comment

Not at all. I only pointed out one reason for a low upvote and that then upvote aren't the best analytics to see how many users are affected by this issue. Also, I even add "I don't want to be rude" to make sure there was no misunderstanding and be sure that my comment was seen only as an observation and not a negative comment.

On the other, @friday you decided to reply with "Linux users have bad reputation." and you continued to escaladed the tension in the conversation. Knowing that, can you stop implying that I made a negative comment. I mean I'm deeply sorry if my phrasing wasn't enough clear and you felt insulted by it. Again it wasn't my intention. Even then, I didn't deserve that backlash from your part tho.

Saying Linux user have a bad rep isn't controversial. Everyone knows it. I'm obviously a Linux user too, and don't benefit from it. Won't comment on the rest of your post since this won't lead anywhere.

@paualberto It's not that he doesn't care. He already spent time on it. There is just too much to do and other issues that are more critical, like always in these situations. "I would not want to add more complexity" is not the same as "I will not".

Clearly there are more people who would like a support of env without a compositor.
I've added contributor-friendly label to #230. If there will be no PRs, I'll try to fix that myself.

Closing comments in this issue.

Was this page helpful?
2 / 5 - 1 ratings