A TWM for Open DSLForum: User Feedback Topic: A TWM for Open DSL started by: hoak Posted by hoak on Jan. 10 2005,01:43
I really love DSL, and it looks like a lot of other people do too! I'm not a huge fan of the Flux Desktop though, as I got to try a system with < Ion > and was spoiled forever. A TWM like Ion would be ideal for a Distribution like DSL because it's very tiny and offers some really progressive advances in User Interface Design that could not only let DSL introduce people to Linux effortlessly but some really cool alternatives Linux offers you can't find anywhere else. I wrote a little introduction to the TWM, and have sort of reedited it here for DSL. A TWM for Open DSL It's my hope that DSL Developers might consider a TWM at least as an option to Flux and others conventional and frequently copied cascading windows, desktop, icons and taskbar paradigm. A lot if not most the of current crop operation system user interface design (mainstream and alternative) is based on making commercially marketable and attractive interfaces that are 'familiar' but are increasingly removed from any real studied analysis of how computers are actually used, or real interface utility -- often even ignoring substantial research and testing that has been done on user interface design. Interfaces incorporating cascading windows, desktop, task 'bar or manager' are very manipulation intensive i.e. the user frequently has to perform an inordinate amount of redundant and repetitive interface manipulation work just to accomplish the simplest task. DCW GUIs (Desktop Cascading Windows) are also wasteful of screen real-estate and clearly comporting useful information without substantial manipulation and re-manipulation. What Is A TWM A TWM -- Track (or Tiling) Window Manager is an alternative to the 'desktop' and 'window' paradigm of the traditional cascading window desktop design metaphor. Fundamental concepts behind TWM design include: · screen real estate is precious · computers may multi-task well but people may not · people may multi-task marginally well but cascading windows make that impossible · complete windows management/customization using only the keyboard · avoiding redundancies through inheritance · reduction of manual window positioning and management The TWM interface paradigm in essence 'tiles' all windows so that 100% of all screen real estate is in 100% use 100% of the time comporting 'visible' information. TWMs typically incorporate default keyboard and mouse shortcuts that allow for automatically resizing windows to preset 'tracks' or sizes according to user preferences and include zooming features to make one window the largest or full screen application. Interface 'widgets' may include a 'tab bar', and/or integrated and unified tool and menu bars that have 'inheritance' features for the dominant application(s). How It Works In a TWM the 'desktop' is the work space and the application interface concurrently -- all open applications may have a window visible as a 'tile' or 'track'. Windows too small to comport normal application content may be reduced to icons, tabs, or some specialized 'ticker' representation of the application that offers relevant information. Sophisticated TWM interfaces like 'Gadgets' for Oberon have unique modular elements that can be dragged and dropped between windows or tracks. The 'never overlapping' paradigm of a TWM makes mouse operations like drag and drop much more practical utility and value, and much less of an exercise. While many early TWMs extol the elimination of the mouse, modern TWMs allow for fast and clever mouse driven window interactions; double click to maximize a window, left-click to re-tile, scroll wheel or click-and-drag to size. Menus, tool-bars, icon trays or even 'in-window' based desktop metaphors can be inherited reducing redundant wasteful interface clutter, excessive mouse movement, manual repositioning and window shuffling. Oberon Gadgets is one of the oldest and most forward looking TWM interface designs, integrating GUI and programming interface with a high granularity graphic object oriented modules and unique user interaction; even the Oberon boot console 'windows' and is a TWM. Benefits · can be designed to less resource intensive then cascading windows systems · make drag & drop or cut & paste operations across applications much easer · automates window management · less redundant mouse movement · less eye strain (Swiss Study*) · allow for shared 'inherited' interface widgets further simplifying the interface Summarily TWM is about making the window manager do the window management not the user. Clarity of information presentation, ease of interaction, interface efficiency, efficacy, transparency and form that truly follows function are paradigms that drive TWM design. Links to hallmark TWMs · < Oberon Gadgets > · < Ion > · < 8½ (Plan 9) > · < TrsWM > · < Ratpoison > · < PWM > Screenshots · < Oberon Gadgets > · < Ion > · < 8½ > · < TrsWM > Although the TWMs represented here for illustration may not be as 'sexy' or 'cosmetically evolved' as more conventional desktop interfaces; there is certainly plenty of room for elaborate facade and art to be added. A Sort Of Summery DSL is a high utility OS, that also offers a great introduction to Linux, that will run on a very light-weight hardware specification, encourages wide distribution due to it's small size, embedded offering and how easy it is to try out. This give DSL a lot of opportunity to expose a lot of Linux Noobs (like me) to some of the real and very functional alternatives Linux offers not available on other Operation Systems that can raise the bar of value and and real utility of the OS. DSL's utilitarian approach to content that appears to that pursue real utility and appeal through form that follows function, and a 'better way of doing things' would I feel be very well served by offing a TWM like < Ion > as an option to it's default interface. A Note I'm very much a Linux Noob and I'm not associated with < Ion > in any way. In fact other TWMs may be much better and more applicable to DSL, and there may be other TWMs I was not able to learn more about and try out (I'm still fumbling with installing this stuff and making it work and only got to try < Ion > because it was already installed on a friends PC). Also there also 'Tab Window Managers' are sometimes called "TWM" and these follow the much more conventional approach to desktop cascading window design. . Posted by ke4nt1 on Jan. 10 2005,02:16
DSL has several different window managers available for you to perusein the repository.. One of your favs, Ion, is posted here for download . Since it requires lua, and lua is now part of the DSL base .iso , it integrates nicely. Several versions of IceWM, evilWM, wmaker, Ion2, etc.. are all available to DSL users, in addition to the development fluxbox version.. < http://www.ibiblio.org/pub....on2.dsl > Nice writeup, and thanks for sharing.. 73 ke4nt Posted by mikshaw on Jan. 10 2005,04:02
I also like Ion (which is why there is an Ion extension ), but considering the amount of effort I've put into customizing and learning everything I can about Fluxbox over the last couple of years I just haven't taken the time to explore it the way I'd like to. A keyboard-driven, low-resource window manager is ideal for any system running ancient hardware, and the fact that Ion uses Lua is an even better reason to try it in DSL.
Posted by AwPhuch on Jan. 10 2005,06:05
WOW!!! You really did your homework!Good job! Is ION now an optional .dsl Kent? Man you are a guru amongs gurus!! Brian AwPhuch Posted by hoak on Jan. 10 2005,09:20
How tough is it to integrate this Ion.dsl into the live CD image? I was looking around about it but don't know where to start...
Posted by mikshaw on Jan. 10 2005,14:09
There are many helpful threads here...a search for 'remaster' should find what you need.I've been wanting to update that extension, though. It was made before I understood tar.gz extensions, and it also could use some additional tweaks (there's hardly any menu, and fonts look bad). Posted by hoak on Jan. 10 2005,14:16
I think I will have to wait for someone else to do it, as I'm a bit in over my head... I understand the principles of all this stuff but when it gets down to making it actually work in practice there are a thousand details...Hope it's a standard 'option' in future 'Live' and 'Embedded' releases of DSL. Ion is really nice and fun to use, even for a Noob like me... In fact I felt more capable with Ion in a few minutes then with something like AfterStep, or Enlightenment that while they look fantastic are a lot of busy work just to figure out and get things done. Posted by Max on Jan. 10 2005,19:01
How do you get the ion2.dsl to work anyway? I tried dropping out of fluxbox and starting up "ion" but that didn't get me very far....I wouldn't mind test driving it just to see how the interface works. Posted by Hoak on Jan. 12 2005,11:10
If someone makes this a option in DSK I'd gladly write a integrated 'how to' that shows how to use Ion (for the way it gets setup), similar to the inegrated documentation in Gadgets/Oberion.... Posted by mikshaw on Jan. 12 2005,14:32
A window manager can't run without first running X. Edit ~/.xinitrc, replacing 'fluxbox' with 'ion', and then run the startx command. Posted by Max on Jan. 12 2005,15:47
After tinkering on my own I got it running. Thanks for the post though.I must say that I was pretty lost once the interface came up. Took me 15 minutes just to figure out how to shut it down. Ion may be efficient, but only after climbing the learning curve. I had printed out both the FAQ and the Getting Started document, but I guess I was just tooo new for even those to help. I think I'll give it another shot once I read a little more. I do like minimalist interfaces. It would have been great if they had had a guide to take you through an example session. (e.g. starting, using and closing common apps, doing some common stuff like moving the tiles around, etc.). Posted by mikshaw on Jan. 12 2005,16:16
Docs are typically ripped out of DSL extensions. I left a few in Ion because I knew it would be a whole new world for some users.There is more documentation available at < http://iki.fi/tuomov/ion/ > Posted by SaidinUnleashed on Jan. 12 2005,16:31
Yes, docs in .dsl's make them more fat, so they get removed.It's a two-edged sword. On one side, we get a (in many cases) MUCH smaller app, for example, the tinyirc.dsl I made. It is, right now, about 12k. With docs, it was about 180k. (yes, its still small, but it's over 10 times bigger). On the other side, this makes .dsl's a lot less friendly to newbs who don't really know what they're doing. -J.P. Posted by Hoak on Jan. 12 2005,18:47
I was lucky I got to play with Ion all put together for me, and everything pre-configured. The setup I played with was very intuitive and even had mouse support going...Oberon was one of the first operation systems I've used and perhaps that spoiled me and made some of Ion's conventions seem more natural and intuitive -- but I think mostly from what I've read it's how much care someone puts into the configuration. I wish Ion wasn't such a Hacker/Programmer's GUI and were a little more in the Linux mainstream, as I think it offer as big a jump in interface efficacy as the addition of the GUI to the command line interface... And I'm sure if more took the trouble to try it out or offer it as an option in their Linux distro we'd see all kinds of improvements... Couldn't DSL's documentation be gzipped and scripted to extrace and open in a default editor or browser to save space? Posted by Max on Jan. 12 2005,20:47
Or if the ion2.dsl was pre-configured for the main apps included in the DSL distro. So you don't have to remember the paths and exact names to everything to get a program to start up.
Posted by mikshaw on Jan. 12 2005,21:36
I've been trying to work up a script that will convert a fluxbox menu into an Ion menu, but so far all it does is throw everything into a single submenu. It'll get better after a while, but mostly it just makes my head spin so far.
Posted by hoak on Jan. 13 2005,04:06
I was reading the updates on the Ion site and came across < WMi >... This looks really promising as it's intended to integrated all the features of all the major efforts in TWM UI design, and do it in a stand alone very compact, low resource environment.< WMii > sounds even more promising, Noob friendly and capable of being 'all things to all users' that are looking for a light-weight desktop alternative with some really forward looking features. I look at this stuff purely from a User's POV so it could all be hooey as far as how good these various TWMs are and how appropriate for DSL... What do you guys think? Posted by mikshaw on Jan. 13 2005,18:53
I have wmi installed....apparently it didn't make much of an impact on me because I haven't used it since it was first installed, and I don't remember why.This menu conversion is giving me a headache. I've had the conversion of individual lines working for months, but the way each WM handles submenus is driving me nuts. Fluxbox is something like this:
Ion is like this:
It seems simple until I start dealing with nested submenus, then my hair starts turning grey. Both of them make sense in their own way, but switching from one to the other is rather confusing. Posted by clacker on Jan. 13 2005,19:30
mikshaw, what program are you trying to write this in? Bash? Anyone else I'd say couldn't, but I've seen what you can do.In psuedo code, you could try this:
Since a string can have embeded carriage returns, you can havce multiple "lines" of output in each string. I don't know what the best language would be. Perl would be good for separating the 3 parts of the fluxbox menu out [exec](name){action} Posted by mikshaw on Jan. 13 2005,19:59
Using Bash...I don't know anything else. Separating the 3 parts is no problem. As I said, the conversion of individual lines has been working for a while. It's the splitting up of submenus that has me stumped, particularly when there is a submenu within a submenu:
As you can see, submenu1 and submenu2 are both terminated by the same string. I just don't know how to determine which submenu is being terminated. I'm thinking of using a bunch of temp files. If it reads a '[submenu]' it starts writing to a file until it reads '[end]' UNLESS it reads another '[submenu]' first, in which case it will write to a second file until it reads '[end]' UNLESS it reads another '[submenu]'. Then it continues writing to the previous file until it reads '[end]' UNLESS it reads another '[submenu]'...etc.... Then I may be able to read those temp files back as I'm building the Ion submenus. To me this is like thinking about how big the universe is, and how tiny atoms are....i follow it so far until my heads spins, and then I have to stop. I'll get it eventually, but it's one of those situations where I have to stay calm, with no distractions, and stay aware of how all the pieces connect. Just writing that last paragraph was beginning to confuse me. I'll read your pseudo script over a few more times...I'm not completely following it at the moment. Thank you. I've already got Ion3 working well in DSL...there's just this last part I want to add in order to keep up with fluxbox menu changes. Posted by clacker on Jan. 13 2005,21:05
I was thinking of it as levels. Everytime you start a new sebmenu, you open a new string and write to that string. If you see an end, end that current string. If you see another submenu, start a new string and write to it. When you finish a submenu, go back to the string before it. You know which submenu is terminating because it's the current one you're writing.Reading my own code, I realize that you would need two array, one containing the menu strings, and another storing a stack for the current and previous submenus. When you start a submenu, you would put the string in the next menu[] and put the string number into the next position in the menu stack. When you finish a submenu, you would pop it off the stack by lowering the stack counter. submenus[30] <= an array of strings holding the submenus submenucount <= an index of how many sumenus we have already menustack[10] <= an array of pointers into submenu[] menustackcount <= an index into menustack to show the current depth Posted by mikshaw on Jan. 13 2005,21:48
I think I understand what you're saying. I need to learn more about arrays before I know how to manipulate them...all I've done so far is create an array once and use it once.
Posted by clacker on Jan. 13 2005,22:26
how are you parsing the lines into their components? Are you using awk or sed? I can't find a good way to do that but I'd like to know because it's useful.I'm tempted to look into perl, since I believe thats good at pattern matching and parsing strings. It would take a lot of learning, and it would be nice to be able to do it in bash anyway. Posted by henk1955 on Jan. 13 2005,22:53
ion uses lua.why not use lua to convert the fluxbox menu to the ion menu? Posted by mikshaw on Jan. 14 2005,02:10
Because I'm making progress with Bash, and I don't have much desire to take on a project like this with a lnguage I know nothing about. Lua isn't going to be any better anyway...it's a text editing project, best suited for tools like sed and awk.I was making some progress...I got to a point where I had defined one layer of submenus, and it should be fairly downhillish from here. However, I'm dumping the project for a little while because of something I noticed in Ion3...it sucks with menu items which have dots in them....it completely chokes on the file and reverts to the default menu. This is unacceptable. I don't recall Ion2 doing this, so I'm going to go back to that one....but only after I stop grumbling about it. Ion3 has some big improvements apart from that glitch. Clacker: I'm using sed mostly. This is the bulk of what I have at this point. The "append_exec_entry" function is what converts fluxbox [exec] lines into Ion format, except that I use awk to remove the '[exec]' part in another section of the script. I overlooked it in the function and just threw it in at the place I was currently working....I'll fix that eventually. The SUBLEVEL variable really doesn't serve much purpose right now...That's what I'm hoping to use to organize the submenu items in the main menu.
Posted by mikshaw on Jan. 14 2005,04:36
well I haven't given up on it entirely, since I'm making some progress. Lua supposedly doesn't have trouble with nested quotes regardless of what type of quotes they are, but Ion apparently does have a problem with it. I converted all the double quotes in my fluxbox menu to single quotes, and that allowed Ion to load the menu. However, it still gives numerous errors that dont make any sense to me...I look at the line in question, and there's nothing wrong with it. It seems like Ion guesses a lot...some of the errors it gave were in relation to nearby lines and not the line specified in the error message.Overall, Ion has a long way to go before it's what I'd consider stable. When you can't use certain commands in its menu its pretty much useless to me. I'm definitely not going to bother with v3 until it gets some of these bugs fixed....so back to Ion2 I go.... /* EDIT: the more I mess around with Ion the less I like it. It's not just the menu items. When I first tried it I thought it was a great idea...and i still do. Unfortunately the configuration is unnecessarily complex, with multiple files relating to what I consider to be very basic features. The biggest annoyance I have with it is its keybindings. First, no window manager should grab single keystrokes by default....that's just plain stupid. Single-key bindings are for applications. Ok, we can change that. But in order to do it you have at least two separate files to edit. One file defines what your Mod keys are, and another file defines what the bindings are. Oh...and did I mention that window managers should never grab single keystrokes? In order to use midnight commander with any sort of efficiency I have to rebind every damn F key to use a Modifier in Ion, and the keybinding in Ion3 uses an entirely different method than Ion2, so that's double the work. Bah...humbug. I'm going back to messing with Screen and Fluxbox.... */ Posted by cbagger01 on Jan. 14 2005,06:57
You need a counter to keep track of your submenu nesting.In other words: You enter a submenu and set submenu_nest=1 You then enter a second (nested) submenu and set submenu_nest=submenu_net +1 (is now set to 2) Then when you hit your first "End" you decrease the submenu_nest counter by 1 When you hit your second "End" you decrease the counter again and now it's value is 0 and you know that you are no longer nesting anymore. Hopefully my example gets the point across. I am not a programmer, but this is my understanding of the technique used in the whitebox program. For a better understanding, download the source code from the website and read it. Hope this helps. [Edit] Maybe I should read the 2nd page of the thread before replying. At least the suggestion to download and read the whitebox source code is still relevent. Posted by henk1955 on Jan. 14 2005,08:16
to make things a like more complicated it looks like this
is a valid ion-menu as you will see the "Programs" menu is nesteted within the:mainmenu. Posted by mikshaw on Jan. 14 2005,19:18
I've quit complaining for now Yeah...that's alright, though. Adding a submenu into the main menu is easy enough, but then you've got nested submenus inside of other submenus. It wouldn't be so confusing except that Ion defines its submenus in a different section, so when you hit a submenu in Fluxbox, not only do you need to know where the submenu is placed but you also need to define the contents of that submenu in a different part of the menu. That definition can also include submenu items. I've made a tiny bit of progress today. The nested quotes have been fixed so that they are escaped in the Ion conversion...now they don't cause errors. However, I'm still having trouble just getting a single level of submenus to be properly written. Many of them overlap each other, making a bit of a mess. When I manually edit the file and move the misplaced 'defmenu' lines to their proper places the Ion menu will load with all of the submenus listed on the same level under the main menu....so I know the individual lines now have the proper syntax (except for commands which include curly braces...that's something that troubles me in other fluxbox-related scripts as well). So next time I get back to it I'm going to start by just gettint the 'defmenu' lines and their terminators properly placed, before considering how to deal with multiple nested submenus. Thanks for the input guys! Posted by clivesay on Jan. 14 2005,19:29
mikshaw -With your bash skills I was wondering if you would be interested in creating something along the lines of MenuRank for DSL. I think the guy who created MenuRank lost interest because I haven't seen anything new for a long time. According to the site, it has a few bugs. I suggested something like this to John awhile back but not sure if he found it worth messing with. It's just a nice little utility for putting your most used programs at the top of your menu. Mainly a convenience app. I am reading up on bash scripting but have a LONG way to go! Chris Posted by mikshaw on Jan. 14 2005,19:51
I don't know...that looks like something a bit beyond my scope. i'd thought about using a fluxbox-menu-related project as a Lua learning tool, though, if I ever get back to reading the docs.One thing that wouldn't be too difficult is making a more basic version of this which just generates a personal menu. Fluxbox-dev has the ability to include additional files within its menu file using '[include] (filename)'. That line could be appended to the top of your menu and load the automatically-generated entries without touching the rest of the menu. As I said, though, it's a flux-dev feature so it wouldn't work in a standard DSL system. I also don't know how to keep track of which applications are being used without modifying the main menu Posted by henk1955 on Jan. 14 2005,20:26
i think you dont have to put the submenus in a subsection!you CAN make it i ONE just like in fluxbox. i you read the example i gave you will see the subsection of "programs" in inside the main menu.
This i a hole, valid, complete, ion menu. i has submenus and is not using subsections Posted by mikshaw on Jan. 14 2005,20:46
Yes, but that would do two things to which I'm opposed =o)1) It wouldn't exactly mimic the structure of the user's fluxbox menu. I want to make it as seamless as possible to switch between the WMs. 2) Having everything under one subsection will mean you have a VERY LONG selection of items to search through. Fluxbox has nested menus inside nested menus, like most other window managers. Keeping that submenu structure identical between the two window managers is my ultimate goal. There are some WM-specific features that won't translate, but it can mostly be done. Posted by henk1955 on Jan. 14 2005,20:52
please try this menu you wil see if works just like fuxbox.menu level 1 shows Programs >> Help About Styles >> Exit >> then level 2 "Programs" shows Xterm Emelfm XMMS Posted by mikshaw on Jan. 14 2005,21:23
Yes, I know.....BUT.....You are digging in only one level. Xterm, Emelfm, and XMMS will all be displayed directly under "Programs" (equivalent to "Apps" in DSL). I've had a menu converter that can do that since July =o).This doesn't account for the fact that a user made menu, as well as the default menu in DSL, is more complex than that. It has multiple level2 entries, which contain level3 entries, which contain level4, etc, as well as various [exec] entries mixed in with submenus on various levels.. As the fluxbox is read in for conversion, there will be multiple times the level will fluctuate, and in order to properly convert to Ion format you need to pay close attention to not only which level you are on, but also which prior levels have not been fully constructed yet and you need to know where to pick up where the level left off. Additionally, the 'defmenu' entries need to be kept up as well. These can just be appended to the end of the file, but while each is being created they have to follow along with the submenu entries being created in case a submenu needs to be added to a particular defmenu. I've got it working to small degree using the temp files, but I had to print out copies of the menus so I can work this out visually. I think I will need to use mutiple counters in order to keep track of the various sections, and I'm also not going to use any of the default menu as a building block within the script...I thought that would make it easier, but it's just a hinderance. //edit I think I'm going to take a fresh approach with this. I've been attempting to do it all with a linear text editor (sed), and that's causing me a lot of confusion. Sed is great for converting the individual lines, but the overall layout of the file probably needs to be handled in another way...how that is I'm not sure, but I'm going to take my two menu hardcopies away from the computer and sit down with a pencil and a notebook..... Posted by mikshaw on Jan. 14 2005,21:50
Holy moley! I didn't notice how you had used the '{' in the submenu line...I guess that pretty much defines the submenu in the same manner that Flubox does. I'm getting excited now....I'll keep you posted... cheers! Posted by Max on Jan. 14 2005,23:01
Had to laugh when I heard your "holey moley"! you just forgot the Batman....
Posted by mikshaw on Jan. 14 2005,23:18
henk: it didn't seem to work =o(Ion seems to get confused about which terminator is used for each submenu...even after carefully checking every brace it still gives errors about expecting a curly brace before a 'submenu'. I cut it back until I had only one submenu within the 'defmenu':
Ion finally seemed to accept this. However, when I pressed F12 i didn't get a menu. So I think it's back to the drawing board.... Posted by henk1955 on Jan. 15 2005,16:52
< Screenshot > of my desktop using the esample menu you give.the only change i made was: defmenu("DSL", { to defmenu("mainmenu", { so the F12 key know where to find the menu Posted by mikshaw on Jan. 15 2005,18:53
Oh...duuuhhhh.....It hadn't occured to me that Ion probably needs "mainmenu" to tell it where to start =o) So now I can build a menu with at least 1 level of submenus without the need to define them elsewhere, so that's a start. I've been toying with various ideas, but it keeps coming back to me getting confused trying to keep up with where submenus and defmenus are being placed. The fluxbox menu is very linear, and it's a bit of a boggler for me when I try to convert it to a non-linear format. Posted by henk1955 on Jan. 15 2005,21:59
this part of the fluxbox menu i convertetd by hand. you can see it is linear. there is only ONE defmenu the syntax is: defmenu( "menuname", { menuentry(" menuentry title", make_exec_fn('command')), submenu( "submenu title1", { menuentry(" menuentry title1", make_exec_fn('command1')), menuentry(" menuentry title2", make_exec_fn('command2')), submenu( "subsubmenu title1", { menuentry(" menuentry level2", make_exec_fn('command3')), }), }), submenu( "submenu title2", { }), submenu( "submenu title3", { }), }) simpliefied that is: defmenu( "title", { sequence of submenu or menuitems seperated by ,}) submenu( "title", { sequence of submenu or menuitems seperated by ,}) menuentry( "title", function()) Posted by mikshaw on Jan. 15 2005,22:50
And this works in Ion?So I must be doing something wrong in my script. I'm saving this page for reference. And if i get it working you will definitely be credited in the script...you are keeping me from completely hating Ion =o) |