Slashdot Mirror


User: setchell.dave

setchell.dave's activity in the archive.

Stories
0
Comments
4
First seen
Last seen
Profile
(view on slashdot.org)

Comments · 4

  1. Re:fluxbox is nice... on From GNOME to KDE and Back Again · · Score: 2, Informative

    Yes exactly. This is kinda a ridiculous topic. Because when it comes to interface, it is just what you, as the end user, want. That is all that matters. I want lean and tiled, for a good reason. Others want pre-configured and predictable, and for good reason. Mac's interface is wonderful, well thought out, friendly and very customizable. So my central point is, I wish that people would discuss features over the glob of entire windowing system. I wish that we could discuss, specific elements that are great about window manager x and window manager y on system z. In lieu of, " the system I use is great and yours sux0rs". Most actual users of their machines use the system they have for stellar reasons, even if they are drastically different from mine. This is good... the issue is that a great deal of wonderful work is spread out across systems; thus few people have all that they want, despite that fact that all their features are out there. They are just spread across many mutually exclusive interfaces.

  2. Re:fluxbox is nice... on From GNOME to KDE and Back Again · · Score: 1

    Yes they do... but the strength of wmii, dwm, and xmonad is that the script then has easy access back to the inner workings of the window manager. Very very easy to say, "start `someprogram` take me to virtual desktop x and call that desktop "myEditor Desk" and place the new program on the top left of monitor 2". Then bind that to . Or find all *terms and bring them to the v.desktop i'm looking at. In the suckless software (wmii, dwm) all settings for the WM are in a live plan9 style filesystem. mod the filesytem then the wm is immediately changed. I cannot speak as much for xmonad { just began using it }. I am enjoying it, just not terribly familiar with haskell. Plus it's tiled. i.e the same key command that starts program "x" will simply bring "x" to the screen. I do a great deal of audio work, which means upwards of 30 open windows at a time. I also need to see them all fullscreen. The first 10 wave files I open are bound ( automatically ) to control 1-10. If I need to see somesound.wav and I can just hit say ctrl 3. No need to alt-tab through crap, or shrink all of them down so I can see them. then maximize. Mind I fully agree this kind of thread can definately be flamebait. That's not my intention. There are some very lean windowmangers ( lean is vital when your cranking 50 some tracks of 96khz audio through and RME ). That have easily implemented features that I'd like lauded and perhaps seen in the "big names".

  3. Re:fluxbox is nice... on From GNOME to KDE and Back Again · · Score: 2, Interesting

    damn straight. dwm and wmii are excellent. The ease of key commands calling scripts that interact with the plan9 style backend == "brilliant". You can type E and via very simple scripting will start emacs and take you to it or if it's already running just take you to it. Nonetheless if you want tiling and dual monitors: i'm really loving xmonad. Took a moment to put my noggin around haskell though. Also, I did like running 2 wmii's one on each screen. But to the point. I do like some of the features of the larger window managers. I just very much wish they tiled, if desired, nativly.

  4. Depending on your on Quality Open Source Calendaring / Scheduling? · · Score: 1

    love of emacs. This is either ideal or terrible. You can run one emacs server. windows, mac and *NIX emacs clients can connect to it. run, calendar.el, remember.el, planner.el, and org.el They all work very well together -> planner can link to the calander for meetings and grab todo's from org.el if desired. Remember can cause any of these files to link each to each other or some arbitrary file [ say tcp report ]. Permissions are controlled by file permission such that i would have a planner page called "DaveSetchell.muse". So, Admins could have direct access to core .org files and the employees planner.el would suck the relevent TODO's from those files to dynamically generate "Task Lists" and mark the calander. just use group permission files for "public stuff" and use the Muse [ which is planner's backend ] for web publishing, if desired.