SEARCH

Enter your search query in the box above ^, or use the forum search tool.

You are not logged in.

#1 2015-03-29 10:31:29

johnraff
nullglob
From: Nagoya, Japan
Registered: 2009-01-07
Posts: 4,148
Website

[DONE] Sort of poor man's debian alternatives...

EDIT: This has now been implemented in BunsenLabs as an extension of the regular Debian alternatives, adding:
bl-text-editor
bl-file-manager
bl-image-viewer
bl-media-player
See later posts for the discussion...

----------------------------------------

The Debian alternatives system is a great idea and works well... for terminal emulators and web browsers. Pretty much everything else it handles is CLI stuff. There is a gnome-text-editor alternative, but not many editors add themselves to it, so not a lot of use.

It would certainly be nice to free our menus and scripts from hard-coded references to a particular text editor or file manager which force users to search around and edit everything when they change an app.

I thought of this system - if anyone can see a snag in it, please point it out before I put any more work into it!
OK ~/.xsessionrc is only referenced in X sessions so it's perfect for setting up stuff which would get in the way in a tty. Let's set some environment variables there, and maybe make symlinks in ~/bin from them, so they can be used in scripts, config files and menus, called with gmrun or dmenu... Then if the user wants to change one of them, it's only one file to edit. Also, unlike alternatives this is per-user, not system-wide.

Something like this:

# edit these to taste:
_BL_TEXT_EDITOR='/usr/bin/geany'
_BL_IMAGE_VIEWER='/usr/bin/mirage'
_BL_FILE_MANAGER='/usr/bin/thunar'
_BL_MEDIA_PLAYER='/usr/bin/vlc'

export _BL_TEXT_EDITOR _BL_IMAGE_VIEWER _BL_FILE_MANAGER _BL_MEDIA_PLAYER

ln -sf "$_BL_TEXT_EDITOR" "$HOME/bin/bl-text-editor"
ln -sf "$_BL_IMAGE_VIEWER" "$HOME/bin/bl-image-viewer"
ln -sf "$_BL_FILE_MANAGER" "$HOME/bin/bl-file-manager"
ln -sf "$_BL_MEDIA_PLAYER" "$HOME/bin/bl-media-player"

We could also put .desktop files in ~/.local/share/applications/ so they would appear in auto-generated menus and can be referenced in tint2rc.
eg for bl-text-editor.desktop:

[Desktop Entry]
Type=Application
Version=1.0
Name=Text Editor
Exec=bl-text-editor %F
Icon=/usr/share/icons/Adwaita/scalable/apps/accesories-text-editor-symbolic.svg
Terminal=false
Categories=GTK;Development;IDE;
MimeType=text/plain;text/x-chdr;text/x-csrc;text/x-c++hdr;text/x-c++src;text/x-java;text/x-dsrc;text/x-pascal;text/x-perl;text/x-python;application/x-php;application/x-httpd-php3;application/x-httpd-php4;application/x-httpd-php5;application/xml;text/html;text/css;text/x-sql;text/x-diff;
StartupNotify=true

Last edited by johnraff (2015-05-12 06:45:32)


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
#! forum moderator    BunsenLabs

Offline

Help fund CrunchBang, donate to the project!

#2 2015-03-29 14:08:07

Sector11
#!'er to BL'er
From: SR11 Cockpit
Registered: 2010-05-05
Posts: 15,667
Website

Re: [DONE] Sort of poor man's debian alternatives...

Don't know if that works BUT looks good if it does, with one ??

Is this needed?

Icon=/usr/share/icons/Adwaita/scalable/apps/accesories-text-editor-symbolic.svg

If you don't use "Icon=" would it default to the users choice in lxappearance?
2015_03_29_11_06_07_540x408_Sector11.jpg
I've switched to "nouveGnomeGray" from AwOken - IMHO I agree with whoever mentioned it before - a nice default for Bunsen.

Setting it as a hard coded choice there makes lxappearance's choice useless.


·  ↓   ↓   ↓   ↓   ↓   ↓  ·
BunsenLabs Forums now Open for Registration
·  ↑   ↑   ↑   ↑   ↑   ↑  · BL ModSquad

Offline

#3 2015-03-30 01:12:55

cpoakes
#! CrunchBanger
From: Tucson, Arizona
Registered: 2012-05-19
Posts: 202

Re: [DONE] Sort of poor man's debian alternatives...

Or you could just extend the existing /etc/alternatives system without reinventing the wheel.  There is no "master list" for alternatives.  They are entirely managed within /var/lib/dpkg/alternatives with calls to "update-alternatives --install" and "update-alternatives --remove" in package postinst/prerm scripts. See the postinst example from xfce4-terminal package below.   

Use this same structure, and run "update-alternatives --install" from the postinst and "update-alternatives --remove" from the prerm scripts in the bunsen package defining the dependencies. Or create a script to run from bl-welcome or the command line.  The advantages: update-alternatives is tested, intended to be extensible, and preserves a single well-documented management interface rather than providing a parallel system.

And I advocate being bold.  Let's parallel x-www-browser and create:

x-file-manager
x-image-viewer
x-media-player
x-text-editor

Build it and they will come.  If it resonates, others will adopt the same conventions; it might even get pushed upstream.  Prefer a desktop-centric approach like gnome-www-browser? We can still use update-alternatives to create and manage:

bl-file-manager
bl-image-viewer
bl-media-player
bl-text-editor

Just add global launchers (/usr/share/applications/*.desktop) to match.

xfce4-terminal.postinst:

#!/bin/sh -e

# install alternatives links

if [ "$1" = "configure" ]; then
  update-alternatives --install /usr/bin/x-terminal-emulator \
  x-terminal-emulator /usr/bin/xfce4-terminal.wrapper 40 \
  --slave /usr/share/man/man1/x-terminal-emulator.1.gz \
  x-terminal-emulator.1.gz /usr/share/man/man1/xfce4-terminal.wrapper.1.gz
fi

# Automatically added by dh_installmenu
if [ "$1" = "configure" ] && [ -x "`which update-menus 2>/dev/null`" ]; then
        update-menus
fi
# End automatically added section
exit 0

programming and administering unix since 1976 (BSD, System III, Xenix, System V, Linux)

Offline

#4 2015-03-30 02:06:31

cpoakes
#! CrunchBanger
From: Tucson, Arizona
Registered: 2012-05-19
Posts: 202

Re: [DONE] Sort of poor man's debian alternatives...

Regarding the existing design proposal:

I don't think these shell commands belong in .xsessionrc for every Xsession.  If I add multiple DEs (like xfce), it puts unnecessary cruft in my environment and sets up a DE I am not using.  This belongs to a more BL specific script like /etc/xdg/openbox/environment or /etc/xdg/openbox/autostart (or the .config/openbox versions if you must).

I think these binaries/links should be global to parallel the structure of x-www-browser and x-www-terminal, not user specific. 

I am leary of managing binaries on the fly but don't have a specific objection (just a gut feeling at this point).  You can't assume the presence of $HOME/bin (or any directory under user control).  You need to add:

mkdir -p $HOME/bin

I don't even like managing the contents of $HOME/bin or even requiring it in the users path.  I think it is the users' domain and should remain that way.  The DE should manage executables in system locations for all users (/usr/bin, /usr/local/bin). 

Maybe define something like /usr/bin/bl-text-editor:

#!/bin/sh
if [ "$_BL_TEXT_EDITOR" ] ; then
    $_BL_TEXT_EDITOR "$@" 
else
    echo "oops, _BL_TEXT_EDITOR not defined"
    # or have a reasonable default
fi

Last edited by cpoakes (2015-03-30 02:20:21)


programming and administering unix since 1976 (BSD, System III, Xenix, System V, Linux)

Offline

#5 2015-03-30 02:18:46

cpoakes
#! CrunchBanger
From: Tucson, Arizona
Registered: 2012-05-19
Posts: 202

Re: [DONE] Sort of poor man's debian alternatives...

And why add leading underscores to the env variables?  This is traditional for system variables that 1) might clash with user defined  names, and 2) are not intended to be modified by the user.  Clearly not your intent given the comment.


programming and administering unix since 1976 (BSD, System III, Xenix, System V, Linux)

Offline

#6 2015-03-30 07:31:53

johnraff
nullglob
From: Nagoya, Japan
Registered: 2009-01-07
Posts: 4,148
Website

Re: [DONE] Sort of poor man's debian alternatives...

@cpoakes many thanks for your input! I was hoping for some constructive feedback like this.

I had in fact been giving serious thought to adding some new debian alternatives, and even now am not totally opposed to the idea. Came up 5 days ago, first brought up in 2013. Original reference here: http://ubuntuforums.org/showthread.php?t=1501719

Why I started thinking about something else:

  1. Editing Debian Alternatives is quite bothersome, involving several long commands in a terminal. Compared with that, my suggestion involves editing one line in .xsessionrc (or perhaps another file).

  2. Edits are done as root, requiring a password. I prefer to avoid sudo as much as possible if there's a userland alternative. Just on principle.

  3. I'd regard the system-wide character of alternatives settings as a disadvantage. Surely it's better if each user can configure their own preferred apps?

Even so, the idea of creating new x-text-editor or x-image-viewer alternatives is rather appealing... especially if the packagers of such apps would add them to their apps' 'provides' fields. Is there actually much chance of that happening?

There does indeed not seem to be any "master list" of alternatives, but there is a list of virtual package names, including things like x-terminal-editor, which has its own page and required behaviour, so obviously some of these "alternatives" are quite established.

cpoakes wrote:

...run "update-alternatives --install" from the postinst and "update-alternatives --remove" from the prerm scripts in the bunsen package defining the dependencies.

Sorry, I'm not following you here. What kind of bunsen package are you referring to here? What dependencies? There will be no BunsenLabs versions of executables like editors.

Just add global launchers (/usr/share/applications/*.desktop) to match.

Again, why use a global system-wide launcher, when you can have individual user files in ~/.local/share/applications?

cpoakes wrote:

I don't think these shell commands belong in .xsessionrc for every Xsession.  If I add multiple DEs (like xfce), it puts unnecessary cruft in my environment and sets up a DE I am not using.  This belongs to a more BL specific script like /etc/xdg/openbox/environment or /etc/xdg/openbox/autostart (or the .config/openbox versions if you must).

I can see a case for moving those variables to ~/.config/openbox/environment, if there was a likelihood or running some other DE where they weren't needed. Though, why would a defined bl-text-editor be a problem on an XFCE session?

The long-term goal of enabling a BunsenLabs session to coexist with XFCE or some other DE's on the same computer is desirable, but not at all easy. CrunchBang never achieved this and early LXDE was notorious for messing with peoples' systems IIRC. I doubt if Gnome or KDE would leave all the settings of other DEs untouched. Anyway, by all means, let's do our best to be good neighbours with all these others...

I think these binaries/links should be global to parallel the structure of x-www-browser and x-www-terminal, not user specific.

This is the same issue again. I'd say - the more user-specific the better!

You can't assume the presence of $HOME/bin (or any directory under user control).  You need to add:

mkdir -p $HOME/bin

I don't even like managing the contents of $HOME/bin or even requiring it in the users path.  I think it is the users' domain and should remain that way.  The DE should manage executables in system locations for all users (/usr/bin, /usr/local/bin).

It's the same grand theme: system-wide vs user-specific. Anyway, surely you're aware that the whole CrunchBang, and hence BunsenLabs, setup is based on a set of user configuration files which are pasted into ~/ at the end of an install? Messing with the user's domain on a grand scale. That's what the whole thing is all about.

cpoakes wrote:

And why add leading underscores to the env variables?  This is traditional for system variables that 1) might clash with user defined  names, and 2) are not intended to be modified by the user.  Clearly not your intent given the comment.

No indeed. I intended quite the opposite. I had got the idea that the underscore was reserved for private variables to keep them distinct from system variables! Google didn't help. Thanks for putting me right there.

Last edited by johnraff (2015-03-30 07:33:44)


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
#! forum moderator    BunsenLabs

Offline

#7 2015-03-31 08:27:48

cpoakes
#! CrunchBanger
From: Tucson, Arizona
Registered: 2012-05-19
Posts: 202

Re: [DONE] Sort of poor man's debian alternatives...

@johnraff 
HISTORY: Thanks for the references to previous considerations about update-alternatives.  I had not seen them.

USERLAND: I appreciate your point about a userland version of debian alternatives.  Doesn't one already exist in the uber-traditional path?

PATH=~/bin:/usr/local/bin:/usr/bin:/bin

The "local" version (same basename) overrides the "system" version, while the "user" version overrides them all.  If I don't like the system-wide x-terminal-emulator, I simply copy or link my own ~/bin/x-terminal-emulator:

ln -s /usr/bin/roxterm ~/bin/x-terminal-emulator

I have employed this method for years (actually decades; it is an old unix principle even predating symlinks).  For compatibility, related desktop files should specify the "Exec=" without an absolute path.  This is the common practice for most /usr/share/applications/*.desktop files (a few sensible exceptions, and a few obstinate exceptions like vlc).

If we create and manage new global /etc/alternatives and establish the related global launchers, then the user can employ the traditional method for customization by creating ~/bin userland copies or links to using the same names.  No script required and the tutorial would teach a general principle, not a BL specific one.

NAME CONVENTIONS:  Thanks for the reference to the virtual package name list, certainly something to consider.  I think creating, using, and refining our own names is the way they become proposed and ultimately accepted as a convention. 

PACKAGE SCRIPTS:  While BL packages contain no "compiled" content, they use standard debian packaging.  In addition to the control and md5sums files, they may include postinst and prerm scripts - even in metapackages.  So if the metapackage includes a dependency for geany, it could include postinst and prerm scripts to run update-alternatives for geany. 

While appearing elegant, I have decided this is actually problematic - the user could remove the geany package without removing the metapackage (assuming no hard dependency) and leave a dangling reference in /etc/alternatives. A bunsen customization script (part of bl-welcome?) might make more sense.  Partial example (script in use on my own system):

#!/bin/sh

update_alt()
{
    local BINPATH=$1
    local MANPATH=$2
    local ALTNAME=$3
    local PRIO=$4

    if [ ! -x "$BINPATH" ] ; then
        update-alternatives --remove $ALTNAME $BINPATH
    else
        [ ! -f "$MANPATH" ] && echo "Bad man path ($MANPATH)" >&2 && return 0
        ALTPATH=/usr/bin/$ALTNAME
        ALTMANPATH=/usr/share/man/man1/$ALTNAME.1.gz
        update-alternatives --install $ALTPATH $ALTNAME $BINPATH $PRIO \
            --slave $ALTMANPATH ${ALTMANPATH##*/} $MANPATH
    fi
}

[ `id -u` != 0 ] && echo "Must be superuser" >&2 && exit 1

# EDITORS
update_alt /usr/bin/geany /usr/share/man/man1/geany.1.gz x-text-editor 40
update_alt /usr/bin/vim.gtk /usr/share/man/man1/vim.1.gz x-text-editor 30
update_alt /usr/bin/leafpad /usr/share/man/man1/leafpad.1.gz x-text-editor 20

# FILE MANAGERS
update_alt /usr/bin/thunar /usr/share/man/man1/thunar.1.gz x-file-manager 40
update_alt /usr/bin/pcmanfm /usr/share/man/man1/pcmanfm.1.gz x-file-manager 30

ENV VARS: I retract.  If env vars become the only way to implement userland alternatives, so be it.  Coexistence was not my problem - crowding my environment with potentially unused vars is what I wanted to avoid. If they never get used again, please unset them and don't export them. That said, I am rooting for the /etc/alternatives version with overrides provided in ~/bin.  No .xsessionrc/environment script required in that scenario.

HOME DOMAIN:  I certainly have no problem when a script or installation establishes files in the users home directory.  But a program that overwrites or fails to preserve an existing configuration is poorly behaved and worthy of a bug report. If I employ traditional methods to copy, link, or modify a program in my bin directory, I expect it to stay that way.  Please, establish a global /usr/bin/bl-text-editor and let me configure my own ~/bin/bl-text-editor if I want something different - the ultimate user control over any executable.

If you are firmly committed to a linking script, please make figure out how to make it conditional and respect the traditional usage of ~/bin.  (This was the source of my bad gut feeling in my earlier post).  And if you decide to actually create a system to manage them as userland options, I think you should not rely on x-terminal-emulator and x-www-browser; you will need bl-versions.


programming and administering unix since 1976 (BSD, System III, Xenix, System V, Linux)

Offline

#8 2015-04-02 02:51:20

johnraff
nullglob
From: Nagoya, Japan
Registered: 2009-01-07
Posts: 4,148
Website

Re: [DONE] Sort of poor man's debian alternatives...

Sector11 wrote:

Is this needed?

Icon=/usr/share/icons/Adwaita/scalable/apps/accesories-text-editor-symbolic.svg

If you don't use "Icon=" would it default to the users choice in lxappearance?
....
Setting it as a hard coded choice there makes lxappearance's choice useless.

Agreed. I picked that icon as the first one I could find as a default text editor, in an icon theme that was likely to be available. If nothing at all was set, it would only get some catch-all ugly "default" icon. Really it would be much better to have some kind of default "text-editor" icon definition that other icon themes could pick up on. Do you know a list of the main default icon names somewhere? I'll do some googling...

@cpoakes - more food for thought, thank you. I'll have to mull all this over for a bit.


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
#! forum moderator    BunsenLabs

Offline

#9 2015-04-02 03:01:46

tknomanzr
#! Die Hard
From: Heavener, OK
Registered: 2014-12-09
Posts: 777

Re: [DONE] Sort of poor man's debian alternatives...

I don't know if this has any bearing on the discussion at hand but I found this in my home directory.
The file is called .selected-editor. Here's what it contains:

# Generated by /usr/bin/select-editor
SELECTED_EDITOR="/bin/nano"

I know this is for command line editors but still it might give some implementation insight.

Offline

#10 2015-04-02 04:58:59

johnraff
nullglob
From: Nagoya, Japan
Registered: 2009-01-07
Posts: 4,148
Website

Re: [DONE] Sort of poor man's debian alternatives...

^interesting...


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
#! forum moderator    BunsenLabs

Offline

#11 2015-04-02 05:04:12

johnraff
nullglob
From: Nagoya, Japan
Registered: 2009-01-07
Posts: 4,148
Website

Re: [DONE] Sort of poor man's debian alternatives...

@Sector11
Found default icon names: http://standards.freedesktop.org/icon-n … atest.html
And it looks as if 'Icon=accessories-text-editor' should work in that case.  cool


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
#! forum moderator    BunsenLabs

Offline

#12 2015-04-02 13:09:45

Sector11
#!'er to BL'er
From: SR11 Cockpit
Registered: 2010-05-05
Posts: 15,667
Website

Re: [DONE] Sort of poor man's debian alternatives...

cool Nice find John ... that should make things easier.


·  ↓   ↓   ↓   ↓   ↓   ↓  ·
BunsenLabs Forums now Open for Registration
·  ↑   ↑   ↑   ↑   ↑   ↑  · BL ModSquad

Offline

#13 2015-04-11 08:47:21

johnraff
nullglob
From: Nagoya, Japan
Registered: 2009-01-07
Posts: 4,148
Website

Re: [DONE] Sort of poor man's debian alternatives...

cpoakes wrote:

I am rooting for the /etc/alternatives version with overrides provided in ~/bin.

Yes, starting to think this is the way to go. x-terminal-emulator and x-www-browser already exist, so we'd have to invent four more. The main aim is to allow menus and keybinds to be set up in the default config that would work for all users. In fact a choice of browser is so personal that it's really hard to see the logic behind making it a system-wide setting with alternatives but that's what we've inherited.

As to x-text-editor vs bl-text-editor I can see the argument about setting an example that might be followed elsewhere, but still lean towards the bl-* version:
1) It makes it clear where it's coming from, who's responsible for its existence.
2) If sometime a genuine Debian alternative came into being, actually supported by associated apps, then our invention wouldn't get in its way. (And we could switch over to using that.)

If the user wants to change bl-text-editor from geany to eg gedit they have two choices:
1) Make a system-wide change. There is a little gui app called galternatives - something like obconf or obmenu in style - that makes adjusting alternatives a bit easier. It doesn't allow the creation of a new generic name, but does let the sysadmin add alternatives to an existing one, or change the selected alternative.
2) Make a personal change with a symlink in ~/bin called bl-text-editor pointing to the desired app., per cpoakes' suggestion.

Four extra .desktop files would have to be added to /usr/share/applications. They would be required in order to put bl-text-editor etc launchers in the default tint2 config.

This should all be doable, no?


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
#! forum moderator    BunsenLabs

Offline

#14 2015-04-11 12:35:54

cpoakes
#! CrunchBanger
From: Tucson, Arizona
Registered: 2012-05-19
Posts: 202

Re: [DONE] Sort of poor man's debian alternatives...

^ I think both x- and bl- alternative names provide a good solution.  I will make one last pitch for x-names. I think this type of innovation comes from the bottom up.  These seem a natural extension of the existing x-names, yet after years of using /etc/alternatives there is no indication these are forthcoming from upstream.  Debian is both slow and conservative to make top-down decisions (a good thing).  Just as importantly when they do, they consider and often adopt solutions modeled elsewhere.  Let's be that model.  I would certainly expect upstream refinements to our model (e.g. standardizing the required options) but it is advantageous for them to adopt an unmodified working system. It translates to faster/simpler development and less testing (we will have debugged it), particularly if we comply with the existing policies for alternatives. 

I hear the concern that upstream might define them differently.  That would require us to make modifications.  But don't bl-names guarantee we will have to make mods?  With x-names we are likely to be the basis of a new standard, and likely to require fewer mods to comply. End of pitch.

I value the option of global alternatives consistent with x-www-browser (be they given bl- or x- names), plus user alternatives consistent with standard use of ~/bin and PATH.  Galternatives seems a win too.  It is always good to have a GUI alternative to the command line interface.  Adding the global /usr/share/applications/*.desktop files implemented with the matched to /usr/bin/* or ~/bin alternatives is straight forward.  Definitely doable.

If you proceed, let me know how I can help.  Since the start of this thread, I have defined and incorporated alternatives for x-calculator, x-file-manager, x-media-player, and x-text-editor on my (wheezy) system to understand it better. There is an issue when linking gvim as {bl,x}-text-editor that requires a script wrapper: only link names starting with 'g' (like gvim or gnome-text-editor) will start vim (vim.gtk or vim.gnome) in graphic mode.  I can send that wrapper to you.


programming and administering unix since 1976 (BSD, System III, Xenix, System V, Linux)

Offline

#15 2015-04-12 01:22:01

johnraff
nullglob
From: Nagoya, Japan
Registered: 2009-01-07
Posts: 4,148
Website

Re: [DONE] Sort of poor man's debian alternatives...

cpoakes wrote:

I will make one last pitch for x-names. I think this type of innovation comes from the bottom up.  These seem a natural extension of the existing x-names, yet after years of using /etc/alternatives there is no indication these are forthcoming from upstream.  Debian is both slow and conservative to make top-down decisions (a good thing).  Just as importantly when they do, they consider and often adopt solutions modeled elsewhere.  Let's be that model.  I would certainly expect upstream refinements to our model (e.g. standardizing the required options) but it is advantageous for them to adopt an unmodified working system. It translates to faster/simpler development and less testing (we will have debugged it), particularly if we comply with the existing policies for alternatives. 

I hear the concern that upstream might define them differently.  That would require us to make modifications.  But don't bl-names guarantee we will have to make mods?  With x-names we are likely to be the basis of a new standard, and likely to require fewer mods to comply. End of pitch.

OK understood, thinking about it.

I was less concerned with what extra work we might have to do if an "official" x-text-editor appeared, than what might happen on the user's machine if there was a clash between our settings and Debian's. I feel it might be safer to keep BL stuff cordoned off a bit, so x-text-editor and bl-text-editor could co-exist. I do appreciate your point about setting an example however.

EDIT: To expand on "a clash". For example, there is no x-terminal-emulator.desktop in /usr/share/applications. (The only .desktop file which calls x-terminal-emulator is gksu.desktop) I wanted to add an x-terminal-emulator.desktop, but what if some upgraded Debian package later installed one? (It seems like a reasonable thing to have.) Debian does not allow the same file to be installed by two different packages, and dpkg would refuse to upgrade and talk about broken packages. If a bunsen package was the cause of such issues it wouldn't help the cause of getting them accepted in the Debian repos some day. So I added a bl-terminal-emulator.desktop instead, with a line 'Exec=x-terminal-emulator'. I think the same would apply to the symlinks in /usr/bin and /etc/alternatives.

Last edited by johnraff (2015-04-12 06:38:25)


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
#! forum moderator    BunsenLabs

Offline

#16 2015-04-12 01:25:15

johnraff
nullglob
From: Nagoya, Japan
Registered: 2009-01-07
Posts: 4,148
Website

Re: [DONE] Sort of poor man's debian alternatives...

cpoakes wrote:

If you proceed, let me know how I can help.  Since the start of this thread, I have defined and incorporated alternatives for x-calculator, x-file-manager, x-media-player, and x-text-editor on my (wheezy) system to understand it better. There is an issue when linking gvim as {bl,x}-text-editor that requires a script wrapper: only link names starting with 'g' (like gvim or gnome-text-editor) will start vim (vim.gtk or vim.gnome) in graphic mode.  I can send that wrapper to you.

Thank you, I'd be interested to see it. I don't use vim myself, but gvim ought to be a viable alternative for *-text-editor.


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
#! forum moderator    BunsenLabs

Offline

#17 2015-04-12 07:44:46

cpoakes
#! CrunchBanger
From: Tucson, Arizona
Registered: 2012-05-19
Posts: 202

Re: [DONE] Sort of poor man's debian alternatives...

johnraff wrote:

I was less concerned with what extra work we might have to do if an "official" x-text-editor appeared, than what might happen on the user's machine if there was a clash between our settings and Debian's. I feel it might be safer to keep BL stuff cordoned off a bit, so x-text-editor and bl-text-editor could co-exist. I do appreciate your point about setting an example however.

EDIT: To expand on "a clash". For example, there is no x-terminal-emulator.desktop in /usr/share/applications. (The only .desktop file which calls x-terminal-emulator is gksu.desktop) I wanted to add an x-terminal-emulator.desktop, but what if some upgraded Debian package later installed one? (It seems like a reasonable thing to have.) Debian does not allow the same file to be installed by two different packages, and dpkg would refuse to upgrade and talk about broken packages. If a bunsen package was the cause of such issues it wouldn't help the cause of getting them accepted in the Debian repos some day. So I added a bl-terminal-emulator.desktop instead, with a line 'Exec=x-terminal-emulator'. I think the same would apply to the symlinks in /usr/bin and /etc/alternatives.

I see your point with the desktop files; they must be part of an installed package's data. I was only considering alternative names.  The class we are discussing correlate to virtual packages which do not exist; they are just names and links.  But the desktop files are actual data.  I feel the x-name structure is strongly suggested by current convention and likely to be adopted by others.  But a scenario where a conflict arises over the desktop files seems likely.   

I would argue we can utilize x-names with bl-.desktops for consistency with x-terminal-emulator and to promote a generic solution, but your point about being accepted in the Debian repos is not lost on me.  We should be bulletproof.  While I prefer a solution usable by the larger Debian community, it would not help our cause if innovation causes a kerfuffle. 

Thanks for the discussion...  Enough bl-athering, time to bl-d it.


programming and administering unix since 1976 (BSD, System III, Xenix, System V, Linux)

Offline

#18 2015-04-12 08:54:11

cpoakes
#! CrunchBanger
From: Tucson, Arizona
Registered: 2012-05-19
Posts: 202

Re: [DONE] Sort of poor man's debian alternatives...

johnraff wrote:

Thank you, I'd be interested to see it. I don't use vim myself, but gvim ought to be a viable alternative for *-text-editor.

Yes, I think any real text editor with an X GUI interface that accepts filenames as command line arguments should be supported. Definition: real text editors read and write text as the native and preferred data format, like geany, leafpad, gvim, gedit, tea, kate, eclipse, scite...

As for gvim, the following wrapper script is usable for x-text-editor, bl-text-editor, gnome-text-editor... whatever you fancy.  It utilizes whichever editor is configured as /etc/alternatives/gvim.  It simply enforces invocation with the GUI interface (-g option) for vim.athena, vim.gtk, or vim.gnome.  For any other editor configuration, the arguments are passed through without modification.

/usr/bin/bl-gvim:

#!/bin/sh
#  Wrapper script to invoke gvim in GUI mode, typically used as target of a
#  link (like /etc/alternatives/x-text-editor).  Rationale: only links to
#  /usr/bin/vim.* starting with the letter 'g' (like /etc/alternatives/gvim or
#  gnome-text-editor) actually invoke GUI mode without using the -g option.

VERBOSE=yes

GVIM=`readlink -f /etc/alternatives/gvim`
SELF=`readlink -f $0`
case $GVIM in
"$SELF")
    echo "${GVIM##*/}: error attempting to recursively execute self" >&2
    exit 1
    ;;
/usr/bin/vim.athena|/usr/bin/vim.gtk|/usr/bin/vim.gnome)
    [ "$VERBOSE" ] && echo "${GVIM##*/}: standard vim, adding -g option" >&2
    $GVIM -g "$@"
    ;;
*)
    [ "$VERBOSE" ] && echo "${GVIM##*/}: non-standard gvim, using verbatim" >&2
    $GVIM "$@"
    ;;
esac

The script should not be installed as /etc/alternatives/gvim; it will exit with an error rather than recursively and endlessly call itself.  The VERBOSE flag is for debugging, and unnecessary for a final version.  Vim-athena, vim-gnome, and vim-gtk are the only vim packages and only official Debian packages that constitute the gvim virtual package.  Any other intentional or incidental link to /etc/alternatives/gvim gets executed without modification.


programming and administering unix since 1976 (BSD, System III, Xenix, System V, Linux)

Offline

#19 2015-04-13 03:09:57

johnraff
nullglob
From: Nagoya, Japan
Registered: 2009-01-07
Posts: 4,148
Website

Re: [DONE] Sort of poor man's debian alternatives...

OK, so let's go with generic names:
bl-text-editor
bl-image-viewer
bl-file-manager
bl-media-player

in Debian alternatives.

Also, make corresponding .desktop files in /usr/share/applications (Exec without full path)
plus bl-terminal-emulator.desktop and bl-www-browser.desktop executing the x-* equivalents.

@cpoakes if I can take up your offer to help - what do you think is the best way to implement the alternatives settings? I was thinking of a postinst script in bunsen-configs for the four new ones. If you agree, would you care to write it? If not, what do you suggest?

Also, where do you consider the best place to put that gvim wrapper?


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
#! forum moderator    BunsenLabs

Offline

#20 2015-04-13 07:20:24

cpoakes
#! CrunchBanger
From: Tucson, Arizona
Registered: 2012-05-19
Posts: 202

Re: [DONE] Sort of poor man's debian alternatives...

@johnraff: I like this structure.  A postinst script seems appropriate in whichever package contains the recommends for geany, mirage, thunar, and vlc (audacious?).  I'll be glad to write it.


programming and administering unix since 1976 (BSD, System III, Xenix, System V, Linux)

Offline

#21 2015-04-13 08:00:04

johnraff
nullglob
From: Nagoya, Japan
Registered: 2009-01-07
Posts: 4,148
Website

Re: [DONE] Sort of poor man's debian alternatives...

In fact, there are no recommends or dependencies in bunsen-configs. It's all config files. At the moment they are mostly templates to go into a new user's ~/ but will also contain some dpkg diversions for things like lightdm.conf. OTOH it will almost certainly have a hard dependency on the BunsenLabs metapackage, without which it would be meaningless. The metapackage can exist without the configs, but not vice versa.

That metapackage (not yet created) will recommend geany, mirage, thunar, and vlc (not audacious - it can't play videos). If a user breaks bl-image-viewer by removing mirage it doesn't seem to do anything disastrous. (Just checked.) The generic name remains visible in galternatives, though it doesn't work of course, and if a different viewer is added there the broken link is immediately replaced by the working one (even if added with a lower priority) and the bl-image-viewer command becomes usable again, likewise if the removed app is reinstalled. Galternatives does not let you delete a generic name, or an alternative if it is the only one.

IOW I don't think we need worry too much about setting default alternatives that the user might break - they are easy to fix.

Anyway, I think bunsen-configs will be the most appropriate place to put the postinst script setting up those alternatives. Most of the files that use them (openbox menus and keybindings) will also be there. An exception is bunsen-pipemenus but that can recommend or depend on bunsen-configs.

Last edited by johnraff (2015-04-13 08:13:50)


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
#! forum moderator    BunsenLabs

Offline

#22 2015-04-13 09:40:21

cpoakes
#! CrunchBanger
From: Tucson, Arizona
Registered: 2012-05-19
Posts: 202

Re: [DONE] Sort of poor man's debian alternatives...

I am confused looking at the github repo... just exactly how many packages are we generating?  I want to address the structure of packaging.  Debian uses the simple names lxde and xfce4 for the top level metapackage to install the "whole thing".  I think we need a similar bunsen "whole thing".  Sounds like this is the intent; it is just not apparent in the repo.

Extrapolating from other common DE suffixes used with "non-binary" content, I want to throw out some example names:

bunsen
bunsen-common
bunsen-core
bunsen-desktop-data
bunsen-artwork
bunsen-artwork-extra
bunsen-theme
bunsen-theme-dark
bunsen-icon-theme
bunsen-icon-theme-faenza

There are two principles at play here.  First, packages are organized into essential and optional as a method to minimize disk usage: artwork and artwork-extra, icon-theme and icon-theme-faenza, theme and theme-dark.  Second, they are designed as functionally replaceable units.  The artwork and icons can be used in other DEs, or replaced by artwork/icons from other sources.  These principles should apply to our packaging; packages should be optional units or replaceable units.

The bunsen configs depend on the pipemenus and the utilities (consider rc.xml without utilities or menu.xml without pipemenus).  No part is optional; together they constitute the core of the BunsenLabs desktop.  They should be a single package.  And they should include common as it is only common to them.  Maintaining a single package is far easier than four interdependent packages.

A reverse use case: a non-BL user wants to employ a single BL utility and would prefer bunsen-utilities (58K) over of bunsen-core (315K).  A quarter megabyte is not significant bloat.  It does not make sense to maintain separate packaging to save one-quarter megabyte for a small population of non-standard users.

I think the packages should be:

bunsen                                     top level metapackage, "recommends"
bunsen-core                             configs, utilities, pipemenus, common
bunsen-hydrogen-artwork         default wallpapers, etc.
bunsen-hydrogen-artwork-extra   optional wallpapers, etc.
bunsen-hydrogen-theme           primary theme
bunsen-hydrogen-theme-dark   dark theme
bunsen-faenza-icon-theme        bunsen version of faenza

The names are merely suggestions. But I really like bunsen-hydrogen better than bunsen1.


programming and administering unix since 1976 (BSD, System III, Xenix, System V, Linux)

Offline

#23 2015-04-13 10:10:27

johnraff
nullglob
From: Nagoya, Japan
Registered: 2009-01-07
Posts: 4,148
Website

Re: [DONE] Sort of poor man's debian alternatives...

The ultimate packaging is still somewhat fluid. The -extras concept for graphics is already agreed and coming. The metapackage(s) have not yet been made. bunsen-utilities was made yesterday to incorporate -exit -lock -user-setup and -wmhacks. Other small scripts will be added to it. So we have the hypothetical package list (meta) and the config files. I think the configs need not be compulsory. It's quite annoying to be forced to install a bunch of stuff you don't want just to get one utility, and I, and other devs I think, would like to keep as much flexibility as possible. Relationships between packages still need thought.

Most of the original package names were just imported from CrunchBang, and some extra stuff thrown in. It's gradually being reorganized, but still rather messy. Please be patient!

Last edited by johnraff (2015-04-14 00:50:02)


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
#! forum moderator    BunsenLabs

Offline

#24 2015-04-13 15:14:10

cpoakes
#! CrunchBanger
From: Tucson, Arizona
Registered: 2012-05-19
Posts: 202

Re: [DONE] Sort of poor man's debian alternatives...

OK! Thanks.


programming and administering unix since 1976 (BSD, System III, Xenix, System V, Linux)

Offline

Be excellent to each other!

#25 2015-04-14 00:52:58

johnraff
nullglob
From: Nagoya, Japan
Registered: 2009-01-07
Posts: 4,148
Website

Re: [DONE] Sort of poor man's debian alternatives...

BTW the default applications in BL Hydrogen will be:

bl-text-editor: geany
bl-image-viewer: mirage
bl-file-manager: thunar
bl-media-player: vlc

I don't think those are too likely to change.

x-www-browser will probably be iceweasel, but
x-terminal-emulator has not yet been decided.
Anyway, the Debian alternatives system will handle those last two for us, setting to whatever has been installed.

Last edited by johnraff (2015-04-14 00:56:29)


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
#! forum moderator    BunsenLabs

Offline

Board footer

Powered by FluxBB

Copyright © 2012 CrunchBang Linux.
Proudly powered by Debian. Hosted by Linode.
Debian is a registered trademark of Software in the Public Interest, Inc.
Server: acrobat

Debian Logo