Jim Babcock | 16 Feb 2009 07:59
Favicon

Proposed compatibility-breaking transition period for LS architecture changes, starting in May

I started to write an article the other day, about my LiteStep module
Screenbar and what it means for themers and for other modules. After a few
sections, it fell into a pattern: explain how something doesn't work properly
in LiteStep (no matter what themers do to cover up the problem), and how my
module will solve it, but will require things to work differently. To solve
the problem of fragile layouts based on manually writing formulas to compute
coordinates, themers can use Screenbar's widget hierarchy, which is more
robust. To solve the autohide, multimonitor and Z-order problems, themers
should make all the little widget modules children of Screenbar, which handles
all these things. Unfortunately, child modules don't work all that well;
modules have to change how they handle the parent paremeter to initModuleEx,
and to have multiple instances (ie, to have a copy appear on each monitor),
some new entry points are required. In other words, everything would work
better, but work in a completely different and non-backwards-compatible way.
There are similar problems with the desktop maximize area and with the start
menu. Screenbar comes with its own, wholly new concept of how virtual desktops
ought to work, which is completely incompatible with RabidVWM and the four-pane
interface that people are used to. On top of all that, the way Screenbar uses
RC files makes you really want to change the syntax. For a module, it's a tough
sell.

LiteStep's problems, however, are much bigger than one module. Some
problems are common bugs that must be fixed in every module of a particular
type. Fixing these problems requires getting rid of all the unmaintained and
abandoned modules. Some are missing functionality which has been added at the
wrong level - modules implementing features that belong in the core, and themes
implementing features that belong in modules. Fixing these problems requires
changing the interface, reimplementing the feature properly, and getting rid of
the broken implementation.

(Continue reading)

chris | 13 Feb 2009 18:12
Picon
Favicon

anonymous cvs access

We are still lacking anonymous CVS access without much promise of change
given the restrictions of our host.

Anonymous cvs access for the community provides ease of access in these
areas:

1. an up-to-date local source tree
2. cvs patches against the latest code base
3. source history/changes
4. code review

Alternative ways to address above items:

1. Provide a script that downloads that source tarball and imports the
changes into a user's local cvs/svn repository.
2. ?
3. Point people at lsdev.org/cvs
4. Point people at lsdev.org/cvs

Solutions we can provide through our host:

1. Mirror to local SVN anonymous read-only repository - requires
dedicated svn.lsdev.org domain.
2. ?

Other (non-ideal) solutions:

Continue looking for a host that can meet the following requirements:

1. Host latest DokuWiki
(Continue reading)

chris | 13 Feb 2009 02:05
Picon
Favicon

CVS Head cleanup

Hello,

I've committed a rather large update to CVS HEAD, the purpose of which 
is to bring the code base into a consistent format.  ie. now everything 
pretty well follows our coding style guidelines, an example being no 
more tabs.

Going forward, please ensure your changes follow the coding style 
guidelines, but most importantly that your changes follow the style of 
the code surrounding your change.

Please examine the diff of your changes prior to committing them to 
ensure that the code formatting is consistent with what exists.

Let's keep a clean, readable, and maintainable code base.  Thanks!

chris

chris | 23 Jan 2009 02:40
Picon
Favicon

LS multi-monitor wrapper functions - deprecate?

With the code in CVS HEAD no longer supporting Windows 95, I see no 
reason to keep the following Win95 specific functions around:

LSGetSystemMetrics
LSMonitorFromWindow
LSMonitorFromRect
LSMonitorFromPoint
LSGetMonitorInfo
LSEnumDisplayMonitors
LSEnumDisplayDevices

However, because modules currently use these functions, I think the 
appropriate solution is to stub them out as direct wrappers to the Win32 
equivalent and place them into lsapi/stubs.cpp.

Also, the core code should no longer use them, and instead directly call 
the Win32 equivalent.

If anyone objects please respond soon.

chris

chris | 31 Dec 2008 20:06
Picon
Favicon

Xjill - you around?

Xjill,

Are you around still?  Please say hello if so and give an update to your status
concerning LSDev.

Thanks,

chris

ilmcuts | 31 Dec 2008 13:42
Picon

Issue states in our bugtracker

Hi,

Happy New Year everyone!

Something in our bugtracker still makes my head spin. We have seven 
states for an issue:

New
Feedback
Acknowledged
Confirmed
Accepted
Resolved
Closed

Their intended use is documented here:
http://www.lsdev.org/doku.php?id=lsdev:bugs

If we can customize those states, can we whittle down the list?

If we can... We never really differentiate between "feedback" and 
"acknowledged". "Confirmed", and "accepted" are also very close in 
meaning. If you don't buy that... There's no clear divider between 
"acknowledged" and "confirmed", either.

My suggestion would be to condense those four to two.

And on a related note... I don't think we need both "trivial" and 
"tweak" for severity either. Pretty much everything is "minor" or 
"major" anyway, and if you do need to deviate from those you have 
(Continue reading)

Gregory J. Weaver | 7 Nov 2008 05:51
Picon

lsdev.org down?

I have not been able to access it for a few days......

Anyone around?

Gregory J. Weaver | 10 Sep 2008 22:25
Picon

test post

this is a test of my ability to post to this list.

chris | 9 Sep 2008 23:30
Picon
Favicon

Common Shell Services and Handlers

Hello,

I'm trying to compile a list of shell services and handlers that are not 
implementation specific.  This is the list I've put together so far:

Dismiss Welcome Screen
Play Event Sounds
Autorun Handling
Hide Minimized Applications
Register Shell Hook
Show Desktop Wallpaper
Run Startup Apps
Create the Desktop Window(???) (MultiMon Aware)
Create the Tray Window
Store and Relay systray icons
Handle AppBars (MultiMon Aware)
Handle WorkArea (MultiMon Aware)
Rude (FullScreen) App Notification (MultiMon Aware)
DDE Service Handler
ShellExecute Handler
Register Shell/Desktop Window(???)

Related item(s):
Registry Configuration to set the shell
Safe Mode Handling(???)

Anything missing?

chris

(Continue reading)

chris | 6 Sep 2008 01:46
Picon
Favicon

server upgrade

I'm looking at doing a server OS upgrade late next week.  This means the 
website, cvs, etc will be offline from 1-2 days.

This upgrade isn't 100% certain yet.

Please let me know if you have any requests for particular software 
updates or features for the server.

chris

ps. We are still looking for someone to join the LSDev team as a 
webmaster and tools admin. ie. someone who can update the web packages 
(dokuwiki, mantis, viewcvs/vc) on a regular basis and implement the 
functionality we want (integrate authentication backends, template 
designs etc).

chris | 20 Aug 2008 18:35
Picon
Favicon

bugs dealing with step.rc parsing API

http://www.lsdev.org/bugs/view.php?id=48
http://www.lsdev.org/bugs/view.php?id=49
http://www.lsdev.org/bugs/view.php?id=51
http://www.lsdev.org/bugs/view.php?id=52

I specifically want to go and fix 48, 49, and 52.  Issue 51 is more to 
illustrate that we need to document the functionality of our API very 
specifically, and ensure it does not diverge from that.

Issue 48:
I think this is essential to fix.  While it may break some modules that 
are currently working around the existing broken functionality, these 
modules can be updated (They are few).  By working around, I mean they 
specifically add an extra set of \"...\" around the variable before 
calling LSSetVariable, which the quotes are then stripped by 
LSGetVariable when they retrieve the variable.  So fixing this would 
cause the quotes to still be there when LSGetVariable is called, which 
may or may not be a problem, depending on their use of the value 
afterward.  We could just bypass this issue and add: LSSetDirective() 
and LSGetDirective() and deprecate the LSGet/SetVariable() functions.

Issue 49:
I don't know if resolving it will break current .rc configurations or 
not.  I would guess it would, but I think the benefit is worth it.

Issue 51:
I don't think this is going to change... It's current implementation is 
a good compliment to GetRCString().  We just need to fix Issue 48.

Issue 52:
(Continue reading)


Gmane