User:Imz

From ALT Linux Wiki


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

More Unix issues that have interested me:

+something implemented about this or that:

/my contributions to free software projects

research on HOW TO do x

I'm posting my experience and thoughts -- "HOW TO do and NOT TO do a certain thing":

See also some other similar notes in Russian: ru:Участник:IvanZakharyaschev/Изучение средств, как что-то лучше делать (а как -- не очень получается).

some random small plans, TODOs, dreams

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 (= bloated) 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:
  1. (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.
  2. (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).
  3. (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.
  4. (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;
  • or 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), try to make new windows maximized by default, make window maximization (or iconification if maximized?) the default action of a double-click on the title. (To distinguish this customization of WindowMaker from the standard one, I'll call it "automatic"--when a name is needed, e.g., in a pkg name.)
  • (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.)
  • (What about Sugar(ALT pkg)? Can it be the base for a DE for grown-up, i.e., combined with the programs grown-ups use: the usual browser, mail client, OOo, etc.?)
With either solution, we 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). As for the file-manager choice, we'd better leave the tested and customized (as regards file associations) one from Xfce. (Or try the WindowMaker's one afresh? File associations could be not essential in WindowMaker, because one can drop the file onto the application in the dock, couldn't they?)
(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:
  1. (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?

No, I think I was wrong. The concern about finding a free place on the desktop is not really conceptually justified: the "Applications" menu is invoked to start a new application, so making the desktop free of old applications (iconifying them) is not a trouble at such a moment--we don't want to work with them right now anyway. Moreover, the need to iconify and de-iconify more often will help teach the user that the row of icons represents the running applications. Also, the repeatable need to click on a "surface" to bring up the needed "Applications" menu will help teach the user this tactics: try to bring up a context menu by clicking on a surface (perhaps, with button 3).

Automatic testing of per-package upgrades from branch to branch

I always get disappointed when I come across the situations when can't smoothly install a package from branch N+1 in a system based on branch N--because of some unforeseen file conflicts or similar reasons (e.g., altbug:25034, a recently noticed simple case). And I spend some time reporting these situations manually to ALT's bugzilla. So I'd like

  • to implement automatic testing for installing packages from a newer branch (including Sisyphus) in a system based on an older branch; and automatic reporting of failures to the bugzilla.
The testing for each new package from a newer branch could be done in isolated "systems" based on the older branch. Probably, the testing should be done in several "maximal" systems based on the older branch; "maximal" means comprising a maximal collection of non-conflicting packages from the older branch.
(Then, there is some hope that I'll spend less time coping with such situations in the systems I use and reporting them.)

Small troubles&workarounds (or solutions)

(Not big enough for a bugreport.)

Problems with ALTLinux infrastructure

Non-delivery of messages sent by automated services to altlinux.org

See Non-delivery of email sent by automated services to altlinux.org