User:Imz

(My name is Ivan Zakharyaschev, Иван Захарьящев, imz.)

research on HOW TO do x

I'm posting my experience and thoughts:

/mini-research on HOW TO edit received messages (which MUAs can and which MUAs cannot do this: edit the subject and insert comments)

comparison of MUAs with respect to this feature [1], my explanation of the required feature on the example of Thunderbird

/mini-research of mail clients w.r.t. to specific features: IMAP, editing of received messages, searching
/research on HOW TO backup an IMAP account (better and worse ways to do it)

some random small plans, TODOs

spaces instead of Russian letters in a menu

to figure out what the source of a problem with xine-ui is: xine-ui's menu (invoked with button 3) shows spaces instead of Russian letters in any Russian locale

(on my "dell" system, where I have been doing single package upgrades, never a dist-upgrade).

I believe it's a problem of a library or a font xine-ui uses (transitively), but which one? The versions of xine-ui or libxine don't seem to matter; BTW, on another my system ("vaio"), there's no such problem; the X server which xine connects to also doesn't matter.

Workaround: gxine or vlc (and these are also the ultimate choice of a DVD viewing program--they have saner UIs; although I'm going to forget xine-ui, I'm still worried about the problem with Russian letters in the menu, because this problem can appear in another program).

Related stuff: In the past, I saw such a problem with IceWM's menu and IceWM's window titles (after a partial upgrade).

better apt-shell (programming with queries to APT/RPM)

Before I look deeper into the problem with xine-ui, I'd like to find a more flexible and convenient way to do complex queries to the RPM and APT databases (the multiple available APT repositories for the different distro branches) than rpm -q and apt-shell/apt-cache combined by Unix shell (through strings). I hope, lua and the lua interface to APT would be more convenient. For instance, in this case, I'd like to do queries like the following:

Look at the versions of all the things xine-ui transitively depends on, and match each of them with a branch of ALT distro. Meanwhile, check whether this problem with xine-ui is present in a certain branch (perhaps, in a chrooted minimal system), and if no, show the differences between my current system and that branch. Think about the differences. (Hmm, it looks like, I'll even need almost nothing special except for hasher and diff for this scenario.)

overt (and simplified) window management

to devise a more clear and convenient desktop environment for those users at home who can't grasp all the concepts of a usual modern complicated desktop environment (windows, window titlebars, minimized windows, applications in the tray) and hence can't keep track of the running applications and manage them efficiently.

(When I set up the system, I used to think that an XFCE would be a more or less acceptable choice (because there is little uncontrolled stuff going on there under the hood and because it's conceptually similar to MS Windows which is usually thought to be OK)), but I have noticed quite a lot of confusion. The problems:

(minor) The titlebar is not grasped as the control for the window (i.e., not part of the application, but a standard application-external control); rather, just it's just some confusing unpredictable text, even perhaps not associated with the window.
(minor) The usual application-specific menu at the top of the window is not seen/found (an application-specific menu is expected anywhere: in XFCE's elements, or deep inside the window).
(important) Taskbar does not give the needed information about the running applications (which might be in minimized windows): as I understand it, the rectangular regions with some text in them (the window titles) don't seem to be understandable, noticeable.
(related) Applications represented by icons in the tray only confuse things and exaggerate the problem with the taskbar: an application may be represented either there or here, no straightforward way to check all running applications.

Additionally, "simplified" window management means that there is no need to resize and move and fit windows, so something like a tiling window manager with one main large tile inside which the active window is always maximized can be thought of as an ideal (although, there are complications in practice: multi-window applications like Skype).

Solutions: I thought of either

xmonad^bugs with one large main tile and all other windows represented by small (square) tiles aside--every running window is visible then and represented always the same way (no other representations: in the taskbar or in the tray); and very bold window decorations (so that windows are clear to be separate entities); and window-switching by selecting one of the small (square) tiles (wish: with the mouse); optionally: a window-switching layout (invoked with a simple key press, say, the Win or the Menu key), where all the windows are equal squares;
WindowMaker^bugs--conceptually, the resulting solution will similar to the one with xmonad described above (but the single representation concept is broken: either a window or a big icon); a plus is that WindowMaker is a ready-to-use solution; some things will need to be tweaked: add an "applications" menu to the dock or another place, disallow window minimization (only iconification), make window maximization the default action of a double-click on the title.
(What about Étoilé? GNUStep-based, similar to WindowMaker, but with a "global menu" (like in Mac OS). Is "global menu" more clear than per-window menu? Perhaps... But Étoilé is not in ALT's repos.)

With either solution, will need to represent the files that previously (in XFCE) were on the desktop by a special invokable window (either a running file manager in xmonad, or a docked file-manager in WindowMaker).

(Kinda conclusion: WindowMaker appears to have a very nice concept for non-professional users!)

helpful "applications" menu

to devise a "helpful" menu; the problem is:

(related) Finding suitable applications and using them through the menu is very burdensome (have to remember the name of the application that was found some time ago in order to use it again).

Another plus of WindowMaker is that the "helpful menu" is already there--just put your applications to the dock.

system "Applications" menu in WindowMaker

to add an "applications" menu button to the dock or another place

I don't like that in WindowMaker the system "Applications" menu is invoked by clicking on a free place on the desktop, especially because I want the windows to be maximized--so, I'll need to add a menu button to the dock then.

Or is the dock is not right place for it conceptually? In the "workflow" in WindowMaker, the dock is the final place for selected applications (the "sink"), the icons for the running applications are the intermediate place, and the system "Applications" menu should be thought of as the source of the applications for the user where he/she looks for them. So, put it on the side opposite to the dock?