Re: [ros-kernel] Re: ROS gui

[Royce M. I. <ro...@ev...>]

> >* keep in-situ start menu editing
>
> and right-click for items. Maybe also give a title bar to submenus, to let
> them be "teared" away and remain on-screen
>

Can the be a compile option. It's sounds rather expensive code-wise, and I
personally wouldn't have a use for it.... I think :)

> >* xp-like user management ( ms finally got that right, if xp wasn't such
a
> >flop )
>
> what do you mean?

I take it you haven't seen Windows XP then. Well, in a nutshell, it works
like this ( by default ):

At login you are presented with a list of users, and each user's icon (
obviously unnecessary ). If a user is already logged in ( wouldn't happen on
boot-up obviously ) then it shows that user as being logged in. This isn't
really why I say it's better, but I can't think of a better way to do this.
The better part is this: User's can log off without having to shut down the
applications they are running. I realize this is a tall order, and probably
would be difficult to pull off, but it is one of the few features I actually
like in XP.

Now that I think about it, there's one more thing in XP we should bring to
the table: XP's compatibility mode. You can tell an application it's running
under 98, ME, NT4, or 2000, and you can have the OS automatically change the
resolution and color depth when running the application. These options are
accessed under a new tab in the file's properties dialog.

>
> >* extension hiding should *not* be default for power users.
> >* file hiding should *not* be default for power users.
>
> well said. Implementing this will also require multiple skeleton/template
> profiles - something that Windows doesn't have

Yeah :(  You have to break some new ground when building a better mouse
trap, huh?

> >* There should *never* be any reason for the OS to open a file unless the
> >user has performed some action on the file, or on a program that uses the
> >file. ( This will eliminate some of the nastier security holes explorer
> >has been plagued by ).
>
> this sounds a bit generic...

You seen nimda? Just hovering your mouse over a file ( you didn't even have
to click it ), and the virus would copy itself.

> >* file associations could work MUCH better. It's always a pain setting up
> >my .c, .h, .cpp, .hpp, etc associations.
>
> any idea about how to do it? I have several, but they would break existing
> programs

Obviously we can't change HKCR. The best thing would be to create a solution
that would work for all windows operating systems. I have a .REG file for my
associations, but it needs tweaking depending on where I install VC and
where I install SciTE. A major major problem I have with the file
associations dialog in explorer is that the "Set Default Action" is
completely broken.

I think that probably the only solution would be to write a simple utility
that reads a REG file, and looks for common paths, and gives you an option
to modify them. Or perhaps reads a REG file, and looks for environment-like
macros ( %vcpath% ), and prompts you to enter what they should be, and if
multiple actions on a file extension, prompts you for which is default (
unless someone can tell me if there's a registry entry for which one is
default - I haven't been able to find such a beast. From what I can tell,
the first action created is always default ).