On Fri, 27 Feb 2015 15:00:01 -0500
Jonathan Wilkes <jancsika@???> wrote:

> On 02/22/2015 07:38 PM, Jaromil wrote:
> > dear Jonathan,
> >
> > you have very good concerns on usability. After Devuan 1.0 we might
> > be able to quick fix desktop behaviour, I bet many developers
> > involved will go do respins and blends.
> >
> > however, for what concerns us here and at least until the Devuan 1.0
> > release (which is a base system) you might have more chances
> > interacting with the XFCE and the Mate projects, which are the main
> > desktop environments Devuan offers on liveboot/install and are used
> > by many other distributions. This way your contribution would have
> > also a broader reach.
>
> Ok, that sounds like a plan.
>
> But which is the default DE for Devuan-- XFCE or Mate?

I don't think it matters. I see four kinds of DEs:

1) No panel (Openbox et al)
2) Panel (Xfce, Lxde, JWM, et al)
3) Inclusion of human ambiguities (Gnome, Unity)
4) Bloatware (KDE, Gnome, Unity)

I'm pretty sure Network Manager would work fine with 2, 3 and 4. Wicd
works fine with all 4. The thing I'm proposing would work fine with all
four, and would depend only on the wpa_supplicant family and whatever
GUI dependencies the GUI version decided to incorporate.

>
> Also, I'll respond below to Steve (I can't find his message so I just
> pasted it from the list archive...)
>
> >On Sun, 22 Feb 2015 20:11:12 +0000 (UTC)
> >Jonathan Wilkes <jancsika@???> wrote:
>
> >Hi Jonathan,
>
> >I rearranged the order of your post...
> /
> >>
> >> Anyhow, if any of those three are missing under the planned
> >> system, I'd be happy to help try to rectify the situation. /
>
> >That's supremely cool. Discoverability is *everything*!!!
>
> Hi Steve,
> I think discoverability is everything, too. But I'd like to
> differentiate discoverability
> from "re-discoverability", which is what you get everytime Gnome 3
> changes its design-mind, or when Yahoo Mail feels like their
> interface isn't cool enough.

Yes. Please modify my statement to incorporate your preceding sentence.

>
> I picked these three features because I don't think they are overly
> complex,

That's for sure. #1 is a fairly easy set of shellscripts, perhaps
front-ended by whatever. #2 is dmenu plus a hotkey, and #3 is just a
hotkey.

> and
> they should be able to provide a decent and stable experience for a
> decade or
> more into the future.

wpa_supplicant doesn't change much, so I'd imagine only the networking
GUI front end would be subject to change.

> /
> >> Hello,A few questions about the GUI for Devuan...
> >> 1) In the default desktop environment for Devuan, will there be an
> >> icon or other discoverable item the user can click to see a list
> >> of available wifi network connections?/
>
> >I can do a lot of the non-gui stuff on this, should we decide that
> >NetworkManager and Wicd aren't sufficient.
>
> >Basically, "iwlist scanning" yields the list, complete with
> >everything needed to show the security type and signal strength.
> >wpa-supplicant and the *horribly documented* wpa_cli to make and
> >break connections and handle passwords.
>
> >I'd envision this as a python-Tk program (connection time is huge
> >compared to executation time, so performance isn't an issue).
> >There's no reason for this system to use dbus.
>
> A few questions:
> * I've read about network manager being designed so that multiple
> front-ends can
> be used. But is the opposite possible? Is there a way to take
> network manager applet's
> taskbar dropdown list GUI and use that front-end on something else?

I don't know. Given the entire NetworkManager's dependency on dbus,


> * if not, would pyqt be a possibility? Tk is of course super-easy to
> incrementally develop,
> but it's missing crucial elements like theming, native dialogs, and a
> slew of other stuff that
> becomes a brick-wall if you want anything more than a
> minimally-working GUI. /

Everything you say in the preceding paragraph is true. I'll just give
you an API, and you can hook any front end technology to it. However...

My way of thinking is this: The less dependency, the better. If *I*
were programming the front end, I'd use the least dependency encumbered
GUI lib I could, and that wouldn't be Qt.

But of course, the beauty of my giving you an API is that you can write
the front end in pyqt, Joe could write it in Python/TK, Sam could
write it in Python/curses, and Dave could write it in C/ncurses.


> >> 2) When the DE's main menu pops
> >> up, will the user be able to _immediately_ start typing characters
> >> and see a list of applications filtered to match what is being
> >> typed?/
>
> >Dmenu does exactly that:
>
> >http://tools.suckless.org/dmenu/
>
> >Dmenu is a productivity fountain without peer, that can be
> >installed on *any* Linux. I wouldn't be caught dead without an easy
> >hotkey to Dmenu. I tweak my dmenu to scroll vertically down the
> >screen instead of horizontally across the top. I also tweak it for
> >max visibility foreground and background, for quick recognition. If
> >you know the name of the executable and don't need to pass it
> >arguments, dmenu is the king of discoverability.
>
> >I also user UMENU:
>
> >http://troubleshooters.com/umenu/index.htm
>
> >UMENU is a spectacular menu program with single keystroke actuation
> >and prompted argument substitution (so you can input arguments). It
> >can be used not only for a "start menu", but also to bolt a
> >discoverable front-end any complex command. However, UMENU has a
> >nightmare deployment process, so less than 100 people use it.
> >Sooner or later, I'll rewrite it to use something other than its
> >current EMDL, so it can be easily deployed anywhere. I'll probably
> >use a directory/subdirectory/file config hierarchy like djb uses.
> //
> Great! I'll check these two out and see how they work.

UMENU would need to be re-architected and rewritten before it could
give you the 10 year longevity you're looking for. Right now UMENU is a
wonderful productivity tool that's very high maintenance.

>
> One great thing about this type of tool is that it doesn't punish the
> user for
> discovering and learning the tool. When you click a start menu and
> navigate some categories, you get worse and worse productivity the
> more you use it-- both the latency and the overhead of navigating
> become obstacles.

Current UMENU is a CLI app. Discoverability via hierarchy only, which
means the person who designs the menu must name categories to make
things discoverable. UMENU doesn't respond to mouse clicks, but you can
type <hotkey>ibf (UMENU->Internet->Browsers->Firefox) faster than any
mouseclick.

Although Dmenu is GUI, it doesn't respond to mouse clicks. Here again,
<hotkey>fire<ENTER> is faster than reaching for a mouse, and discovery
comes from the narrowing of executable names.

>
> But with these kinds of tools you can eventually learn to bring up an
> app faster
> than your eye can track the animation of the tool. A graphical tool
> that can
> rival the speed of the command line in any domain is a decent design
> IMO.

Yes. With both dmenu and umenu, eventually your fingers learn the riff
for often issued commands, and it doesn't even interrupt your train of
thought. Both of these command spawners are perfect for the touch
typist who likes to remain at home position.

>
> Btw-- I do not mena to imply _replacing_ a point-and-click menu or
> right-click
> menu in a DE./

Oh heck no. Both exist in parallel with whatever the DI offers.

>
> >> 3) In the default desktop environment for Devuan, when the user
> >> clicks the "Super" key (often has the Windows icon on it) will the
> >> DEs main menu pop up?/
>
> >I think the preceding is just a matter of hotkey assignment, and of
> >course is a good idea.
> /
> >> I put these three features in order of
> >> importance for newcomers and non-technical users to have control
> >> over their machines. #1 is vital because it makes the entire
> >> knowledge-base on the web (potentially) available for users so
> >> they can troubleshoot problems outside of network connectivity,
> >> even if they haven't a clue what an ESSID is.
> >> #2 is important because
> >> responsive natural language searches are ubiquitous, simple to
> >> understand, explain, and remember, especially when compared with
> >> branches of app categories (which are often quite arbitrary). /
>
> >One of the executables that comes with dmenu can take any sorted
> >list and intelligently reduce with each user keystroke. Dmenu is
> >modular, so one executable searches the execution path, delivering
> >a sorted list of executables to the second executable, which
> >reduces the list based on user keystrokes. The selection then gets
> >processed by a third executable to run the program. Bottom line,
> >dmenu could conceivably be used for a lot more than running
> >programs.
> /
> /I'll definitely check it out/.
>
> >> #3 is
> >> certainly not vital at all, but its existence is a good indicator
> >> that the developers take usability seriously. You may be able to
> >> guess that I currently use Gnome 3 under Debian, because Gnome 3
> >> includes all three features that I list. But please don't be
> >> mistaken-- I'm not looking to pitch Devuan on Gnome 3. Rather, I
> >> have neglected to uninstall Gnome 3 because as long as it does
> >> those three things it fulfills my needs as a user. I'd much
> >> prefer to use a distro like Devuan, where its community is
> >> reflecting upon the long-term maintainability of the system (and
> >> closely inspecting its source code). As long as it has a default
> >> DE with the three features above, I can switch over with
> >> virtually no pain. But more importantly, with those three
> >> features an entire class of non-technical users can have a safe,
> >> sane, and secure place from which to launch Chromium. I'd bet a
> >> large chunk of Lenovo's userbase has a desire for just such a
> >> system atm. :)/
>
> >I hear you Jonathan! For new users and people whose core competancy
> >isn't computers, discoverability is king, and discoverability is
> >exactly what your three wishes provide. Moreover, discoverability
> >is a timesaver for even the most experienced users, because nobody
> >memorizes everything, and we all use new software sometimes.
>
> >I can also help.
>
> Cool! I'll check out dmenu and umenu when I get some time. Once
> Devuan gets to a
> point where I can easily download and install a relatively stable
> release, I'll start looking
> at this in a more concrete way.

Please keep in mind that UMENU needs to be completely refactored for
easy deployment and the kind of 10 year version stability you're
looking for. On the bright side, UMENU has a 16 year track record of
basically the same user interface, which I don't see changing. All that
needs to change is the method of storing the menu data, and the
installation and menu alteration methods. As far as Dmenu, it's good to
go right now.

The past week I've had a horrible stiff neck that's cut my productivity
by a factor of five, so I haven't even looked at any of this stuff. By
March 10 I should know what's wrong with me, and unless it's something
horrible, I should be back in action.

Thanks,

SteveT

Steve Litt                *  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance