Hi I read this with much interest as I also believe that the visual interaction paradigm in WIMP is somewhat limiting and has done much to establish BLOAT BUTTON oriented interfaces that BURN UP screen real estate and MEMORY and offerlittle in the terms of better visual interface or information display and management (if you consider eye-candy more or less useless as I do) then wmii represents the begining steps on a journey toward a keyboard oriented GUI paradigm which I believe is much more interesting and humanly adaptive since alternative interfaces like speech or touch are mapped to either sound words or screen elements which like a mouse is cumborsome for fast and accurate input - thats why accounting still has 10 key number oriented key boards, phones still had 10 digit dial pads and advanced highly interactive applications still use keyboards in things like music or structural display applications like those used in oil and chemical industries.
The trick I believe we need to pull off is to rethink the ENTIRE interaction model and how the software components interact on the screen and how we commonly use them. To that end wmii represents the visual engine to do that. We just need to build the algorithms and that database mappings to structure the common working elements into nice visual arrangements that represent our visual interactive working arrangements... To this end wmii is then the future visual glue and placement system to make that happen. I also believe the window bars on each window are a waste of SCREEN space and detract from the visual experience as they are just stubby horizontal elements that you always have to LOOK at even when you are not using them... Just a few cents from the peanuts gallery... But I believe a worthy few cents. regards, Joseph Altea, Found ImerXion LLC - Unix GUI programming without the GUI BLOAT in wmii and Plan 9 windows systems. Look for Wmii applications (WIMP FREE and NON WINDOWS BLOATED) coming soon.. to Linux,FreeBSD,Plan9, and OpenBSD. IF you would like to discuss use these emails below: >>> [EMAIL PROTECTED] or [EMAIL PROTECTED] <<< On Wed, Apr 05, 2006 at 02:32:25AM +0300, Nep wrote: > I was thinking about the way the windows are resized when other windows > appear/disappear from the view. the present way works but I'm not sure it's > the best. > > I often resize my windows so i have a large one and another or others of > smaller size. > > Now if i need let's say a terminal for a few commands the proportions are > lost. > > When i finish my work with the new window and close it I'm left with windows > of all equal height. > > A better way for some (maybe it could be specified in the wmiirc file) would > be to resize windows according to percentages of the screen estate they take > up. > > Situation: 2 windows on the screen. a window (w1) that takes up 70% of the > screen height and another one (w2) that takes up 30% (no columns). a new > window appears on that view. > > Then the height of the new window would be 1/3 of the screen height.(like it > already happens) but the the height of the others would be 70% and 30% > respectively of the remaining 2/3 of screen. > > I think this could be implemented without too many complications.. it just > means some additional calculation: > > ex: > > n windows present on screen: w_1,w_2... w_n > > their heights: h_1, h_2,... h_n > > ScreenHeight: H > > > when a new window w_n+1 with height h_n+1 appears: > > height of new window: > > h_n+1= H / (n+1) > > > recalculate heights of existant windows: > > x from 1 to n > > h_x = h_x/H * (H ? h_n+1) > > > The reverse when a window is closed. > _______________________________________________ > [email protected] mailing list > http://wmii.de/cgi-bin/mailman/listinfo/wmii _______________________________________________ [email protected] mailing list http://wmii.de/cgi-bin/mailman/listinfo/wmii
