bobstart (gui for managing desktop autostart items)

Forum Forums Kafeneio Chats In a Greek kafeneio bobstart (gui for managing desktop autostart items)

  • This topic has 23 replies, 4 voices, and was last updated Jan 2-2:39 am by skidoo.
Viewing 9 posts - 16 through 24 (of 24 total)
  • Author
  • #14643

    Super! I removed the dex package and downloaded the dex-master zipfile from git, and installed the dex executable in /usr/bin and changed the startup to use the -s option, and all works now.

    My wife just wants to select programs, not edit things. Actually, if the .desktop entries were only 3 lines, she might get more adventurous.

    I see nothing wrong with having things that default well enough for most people to easily get the basic things they want, and providing manual editing functionality for the techies that want neat things and are willing to get their hands dirty to have them.

    I installed Eclipse and Pydev and Gdb to be able to debug, but it had problems finding the imports. It looks like its working now, but I don’t know what fixed it. I will have to try that another day.

    Thanks again 🙂


    after .desktop entry was created in ~/.config/autostart I was able to tweak the .desktop file via the edit command and bring up MC with an LxTerminal-MC .desktop

    Excellent, but we can’t expect wife (or daughter…) to do casually this.

    Could point users toward documentation which presents examples & explains the task of editing/customizing existing launchers (.desktop files)

    Skidoo, But what could be done would be to provide .desktop icons for the ones that many people use all the time and are installed on all antiX platforms by default, like Midnight Commander for example. I use that one every day. The .desktop entry could be created similar to the MC Editor or AlsaMixer entries. What is odd is that MC has a menu entry, but because it’s “Terminal=True”, instead of “desktop-defaults-run -t mc” it doesn’t appear. Maybe that is the solution on the Terminal=True ones, just convert them as part of the copying process, or maybe just convert the default .desktop files.


    One problem is that if you edit an autostart entry that you just added, it instead tries to edit the original .desktop file. I looked but don’t understand the language well enough to know how to tell get_filename() to get the name of the new file instead of the old because its not obvious how I could tell it to use the new filename instead.

    If the autostart entry is already there coming into the program, it does edit the correct file, so that leads me to think the list its working from is from when the lists were created.

    I have a tough time with the whole program because I don’t know what its supposed to be doing (ie basic questions like what is a tweak) and can’t follow how it works due to the objects and not being familiar with how they are working. Obviously, I haven’t got the debugger working, still, or at least I would expect that I could step it through, see the values stored and learn more.

    I don’t expect anyone here to teach me any of that. I will make another attempt at the debugger to step through it, since I need to be able to follow what’s happening to be able to understand it.


    Question on Python, debugging, Eclipse, pydev, gdb

    I tried pdb and it wasn’t good. It seems like pydev is supposed to be good.

    The most relevant youtube videos I found all load Python, Eclipse and Pydev directly from their internet sites. Should I be doing that or from the repos? I did it from the repos, but wonder if that is going to cause problems?

    Forum Admin

    I am a little lost…As far as doing what?

    Running the script and making the changes? That can be done by opening the terminal, cd to the folder containing the script, chmod 755, and then run it as ./ This will start the program and if there are any errors it will show the error in terminal and (possibly/ closely) the line number. You can then review and edit the code with geany.

    As to following the code, yes it is more difficult than other scripts. Skidoo’s comments and name changes are quite a bit of help in that script. If trying to trace calls to other parts of the script you can search the call string you would like to follow and it should eventually find the variable / function for the most part. Though not always the case…

    Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown


    the “Tweak” nomenclature in the code was inherited from the gnome-tweak-tool (as seen in Budgie desktop). Much of the spaghetti was due to the complex ui layout of the original. It had a left pane plus split right pane. Clicking “stuff” in the left pane caused the right pane content to be repopulated.

    Tonight I reworked the script, brought it down to about 250 lines of code (plus inline comments). Now I’m going the other direction, adding stuff back in ~~ replacing the opaque Gio.app_info_get_all() with more verbose, and commented, code which utilizes xdg.DesktopEntry().

    “Right-click to edit/customize items in the top pane” is off the table.
    In fact, the first line of the “CAVEATS:” commentary now states “DO NOT EDIT ANY .desktop FILE(s) WHILE bob2start IS RUNNING”
    If you want to mess with creating custom launchers, dodging “Terminal=True” by using, instead, “lxterminal -e bash -c| foo and a side-order of fries…” you can copy or edit/SaveAs to a new (new, distinct, different) filename inside the ~/.config/autostart directory.

    Inline notes at the foot of the script will provide details, but in a nutshell:
    on the antiX Full system I tested, 50 of about 180 prospective .desktop files are blacklisted as unsuitable candidates for bob2start. As an inexact rule-of-thumb, if the Alt+F2 (gExec) runner is unable to successfully launch a given launchstring (as seen in a Exec= line within a given .desktop file), launching via dex will probably be similarly unsuccessful.

    debugger? Yeah, exactly what Dave said. FWIW, I’ve added several more print() statements peppered into the code & will leave ’em in place, outcommented, awaiting your potential perusal. Python IDE called “Eric” is probably my suggested tool, but many months have passed since I last launched it, because: when python encounters an error, the line number(s) and details it outputs are nearly always sufficient to identify the exact faulty line of code.

    What is odd is that MC has a menu entry, but because it’s “Terminal=True”, instead of “desktop-defaults-run -t mc” it doesn’t appear. Maybe that is the solution on the Terminal=True ones, just convert them as part of the copying process, or maybe just convert the default .desktop files.

    In the revised script, the rule-checking and the names like “valid_candidate” should help to clarify the plumbing. In reply the the 2nd quoted sentence: I’ll leave that (fiddling/testing) up to you. Unlike testing from commandline in terminal emulator or console, unlike “adding an ampersand terminated line in the startup file”, you will need to test how well (or not) a launchstring (and any passed env variables) survives being exec’ed in the context of a dex “spawn-and-disown” subshell.

    maybe just convert the default .desktop files

    If “convert” means you’ll open an existing .desktop file, edit it and SaveAs (to ~/.config/autostart dir), we’re on the same page. If you’re considering editing-in-place the /usr/share/applications/ -resident files, I’ll mention from experience that’s a bad idea; package upgrades often (frequently/regularly) overwrite those files, undoing your customizations.


    The most relevant youtube videos I found all load Python, Eclipse and Pydev directly from their internet sites.
    Should I be doing that or from the repos?

    Nooooo! and Yes.
    (IMO, doing the former is analagous to “bend over, grab your ankles… and prepared to be pwned!”)


    Skidoo, Yes, you are right, converting them at the point of them being added to the autostart apps list makes sense.

    Both, I was looking at the debugger as a learning/analysis tool because I was trying to change/enhance, not fix any error message.

    I’ve never successfully written a program or even done any major tweaking of a program using objects (like a dinosaur here), so the whole methodology is very foreign and I can’t see from the code what happens when or why, and my idea was to step it through watching what’s happening to learn from doing so. Given that, the code was hard for me to follow. I used to do the “print” thing for debugging basic programs back in the 70’s and 80’s, and still use it in batch scripts where I don’t have a debugger.

    I’m required to use Eclipse at work, and although I don’t like its keyboard or mouse setups as an editor, I’m not lost trying to use it. I had to make some setup changes to get the program to work with pydev and eclipse, and I guess that’s just the reality, and probably would have been necessary whether I installed the older repo versions like I did, or from the websites and risked of integration problems with the menu, path, anything Debian or antiX specific.

    When you get your sleeker version done, post it, please, and I’ll try it on my test system.



    BobC, here’s a “version2” of the same utility script.
    At this point, I’m sharing it for the sake of its inline notes/commentary, NOT for its code quality.

    FWIW, there’s not much user benefit from changing away from using version1.
    Version2 still lacks consistently-sized “Icon” images (as noted in the code, I lack the patience to rewrite/workaround)
    but entries in the “add item” picklist are now presented alphabetically.

    Contrary to what I stated in an earlier post, I’ve discovered/realized while tinkering on this project that a line stating “Type=Application” ought to be considered as one of the “bare minimum” lines necessary for a *.desktop file to be effective (to be universally recognized/handled as a “launcher” item by xdg-compliant handlers.)

    Day-um! Geez the python-xdg parser is overly strict. Across years I’ve formed the habit of selectively “outcommenting” lines within a .desktop file by placing a semicolon at start of line to cause the line to be ignored. (Example: after installing a program and finding no menu entry autocreated for it, due to presence of a “OnlyShowIn=Gnome” line). Well, although I’ve never previously noticed that practice causing a problem — and ida swore I’ve read it recommended, within documentation, to outcomment rather than remove selected lines — the python-xdg parser raises an exception when parsing those outcommented lines.

Viewing 9 posts - 16 through 24 (of 24 total)
  • You must be logged in to reply to this topic.