I wouldn't have had to create a new thread if the first of this hadn't been locked :P

While that link to the other thread does tell end-users how to employ a 3rd-party app to change window styles, downatone's posting is something different.

His is a suggestion to add that functionality to litestep. Sort of like ages ago when someone said "sure there's a bunch of really good 3rd-party apps for (notes/system metrics/clocks/quicklaunchers) but that seems like something the shell should have integrated.."

It's easy to point someone to a 3rd-party app to replace the need to code the features into litestep, but if we're just going to point everyone to 3rd-party apps then we might as well stop development on litestep modules altogether :P

"No need to improve rainmeter or fix any bugs in it, people can just use another app.. No need to add drag-n-drop functionality to any of the quicklaunch modules, people can just use an app instead.."

Sure, it's easy for me to get on my high-horse and say these things should be developped and implemented within litestep, as I'm not a developper and it's not my time that's being sacrificed to bring these to fruition.. It just bothers me when something with the potential of litestep gets subverted in favor of 3rd-party apps that can be made to work with litestep, but are not actually integrated.

This topic especially applies, as the window appearance is SPECIFICALLY something that should be handled by the shell, not a 3rd-party app.. If litestep took the reins for window skinning the way it did for module skinning, we could add lots of functionality to the windows - instead of having a button to minimize, a button to maximize, and a button to close, we could have a button to pin the window always on top (or pin to the bottom desktop), a button to toggle the transparency of the window, a button to execute some custom bang script, throw in a volume slider, the date, and the time, maybe even a button to send the window to the next desktop if you just wanna get it outta the way quickly :)

By integrating a new feature into litestep instead of referencing someone else's app, you're allowing the user to further customize the elements pertaining to that feature, possibly and probably much more so than they could with the 3rd party app. Also you're contributing to the evolution of litestep instead of hindering it.

Anyway, just wanted to raise my fuss as there've been a few different suggestions I've seen over the past little while that would make EXCELLENT improvements to litestep, but get discarded as "superfluous" as there are 3rd-party apps that accomplish *some* of the functionality that is sought. The basis of litestep is to have an interface that allows the user to customize every element to fit their needs/tastes.

So there's my 8 cents to go along with downatone's 2 cents :)

PS - Deuce, please don't take any of this as a personal affront. I know you're just trying to be helpful :) And frankly if I was an end-user who just wanted to get funky-lookin windows I'd rather someone point me to a 3rd-party app than say "It's in development, wait a few months.." ;) But ideally I'd like to have someone point me to a 3rd-party app that can do the job in the meantime, *AND* be able to say "it's in dev.." :D

whoa man! u just looove to write, don't u ;)
/me had to get that out of the system...

if i think of anything useful to say... i'll be back :)

How many times have we been through this?

Even if you go through all the trouble to do this you'll find that there's no real LS dependency. A module like that can easily run as a separate program, the only thing you may have to change is the way you look up your settings, e.g. from an INI file instead of step.rc.

But why stop with an LS module that skins windows? Why not make LS an entire win32-compatible Operating System? Why not use it to fly to the moon? Because those things aren't within litestep's scope. And because there are other dedicated apps which can do this job much better than a project limited to LS ever could.

If you find someone to do this, fine. But limiting the result of your hard work to just one shell doesn't really make sense here. You have to spend so much time debugging such a module/app that it needs a development team of its own. And I wouldn't want the window skins to un/reload on every !recycle anyway. :P
Btw, that's why so few people use 0irc as an LS module... dedicated apps can do a much better job, and if you do want to run 0irc (I do on my P90 downstairs) then you'll usually want the standalone version.

But I digress... look at the ShellWM effort and try to imagine what would have happened to it if it was an LS module and thus limited to those who run LS. It would have quickly died. It's barely alive as it is. I'm all for a module that integrates LS and ShellWM of course, a module that tells ShellWM what skin to load for example. You'd put a "ShellWMSkin" line in your step.rc to configure it... or something along these lines. But the ShellWM core should really stay a separate project.

You raise very valid points ilmcuts.

I do feel something should be created to allow modules to be hooked into window captions or scrollbar areas like they can into lsboxes, which *is* something that would be litestep specific, but you're right - a window skinning engine need not be limited to litestep and is certainly beyond the scope of the dev team.

Perhaps simply adding a way to check if windowblinds is running, and a module to hook a specified module into a specified window class/caption combination. That way you could do something like



I suppose the problem would be that more than one app could then try to hook the same module, and hilarious antics would ensue.. Perhaps it could just hook the modules to whatever window has current focus, then unhook it when that window loses focus?

this has been raised countless times in the past (ls window skinning module) but you're the first to suggest putting modules in the window titlebar.

interesting idea for sure :)

/me wonders if it's even possible.

Microsoft's shell doesn't handle drawing window borders either. That's the window manager's job. (If Windows even has such a concept.)

In theory, litestep modules probably could hook themselves into arbitrary windows (tasks-0.92 probably already has this capability in a limited form, see "docking"). Attaching to the caption area isn't particularly special, but it does require knowing a lot about how it's drawn so this can get positioned correctly. I don't think multiple modules attached to one window would be a problem.

Right now ShellWM is being coded by ONE person, Floyd25.

He has Issused a "Call to Arms" of sorts for new blood to impower progress. I can't code... yet. But I'm sure someone here could help with ShellWM.

If someone from here got in contact with Floyd25 to be a coder for the prog they could help steer it into module "like" format for litestep and useable for all people.

Here is his message and a link to the site.

Guys, I really need some help with this prog. Looking at the latest site
stats reveals that there were 1000s of people visiting this site and
100s of them downloading shellWM.

I know that many people are using shellWM and it's
giving me a headache that so many users are actually using
a buggy version of shellwm. If I only had more time to
bring out a fresh version.

Is there anybody willing to help with programming this beast ?

Thx,

Floyd25

http://shellwm.sourceforge.net/

You can have buttons, taskbar, systray or whatever automatically docked over the active window with RabidVWM, a timer and a script to move all the stuff :)