Tuesday Jun 13, 2006

Changing the default login session in dtlogin

At some point over the past few years, I somehow went from just checking in the new login and splash images for CDE in each Solaris release to becoming the unofficial dtlogin “special ops” person - handling the overhauls of the dtlogin appearance for the Solaris 10 beta, 3/05, 1/06, and now 6/06 releases and a few other side tasks that the main CDE sustaining team didn't have the resources to handle. The latest of these is shipping in Solaris Nevada starting in build 39, and I've just gotten the draft of the release note for the upcoming Solaris Express release including it:

Default Desktop Session in dtlogin

Now, when a user logs into the Solaris Desktop for the first time, Java Desktop System (JDS) is the default desktop environment instead of the Common Desktop Environment (CDE). JDS has also become the default environment for users who chose a desktop environment on an older Solaris release that is no longer present in the Solaris release, such as OpenWindows or GNOME 2.0.

System administrators can modify the dtlogin configuration to override the default choices using the defaultDt and fallbackDt resources.

For more information about defualtDt and fallbackDt resources, see the dtlogin(1M)man page.

So users who already chose CDE or JDS will have those choices respected - this only changes the defaults for new users or those whose current session can't be found.

For comparison, the description I wrote for our Architecture Review Committee (ARC) has a lot more technical detail (some of which is now also captured in the above mentioned dtlogin(1M) man page):

This case introduces two new resources in the dtlogin Xresources file
(/{usr,etc}/dt/config/$LANG/Xresources) and establishes initial default
values for those in the Xresources files shipped by Sun.

It requests a patch release binding.

1) Dtlogin\*defaultDt:

   When a new user logs in for the first time, a dialog box is presented
   asking which of the desktop environments installed on the machine they
   wish to use.   The default list currently consists of CDE & JDS, but
   any additional desktops installed using the altDt support in dtlogin
   will appear as well.

   This resource controls which of those desktops is selected by default
   when the dialog appears, so a new user who doesn't know the difference
   and just clicks the OK button will get this desktop, but those who know
   the difference can still choose as appropriate.

   The value of this resource must be the altDtStart value of one of the
   desktop environments installed on the system.   (This was chosen since
   it is the one value required for all desktop environments that must be
   most stable, since it is the one recorded in the lastsession file in
   the users home directory to store their chosen desktop.   The altDtName 
   is localized, so not appropriate for a global default setting.  The
   other values for altDt\* settings are all optional and may not be present
   for certain desktops.)

2) Dtlogin\*fallbackDt:

   When an existing user logs in, but the lastsession file in their home
   directory refers to a program that is not executable on the current 
   system, dtlogin will execute the program listed here as a fallback session.

   This may be any program, including /usr/dt/bin/sdt_firstlogin to offer
   the users a choice of the sessions available on the system.



The default X resources files shipped in Solaris will contain these additions:

!!  Default desktop choice for new users in initial login dialog
!!  This should be the altDtStart key of a session defined here or in
!!  an Xresources.d file.

Dtlogin\*defaultDt:	/usr/dt/config/Xsession.jds

!!  Fallback desktop choice for users whose lastsession file refers to
!!  a non-existent session choice.  Set to /usr/dt/bin/sdt_firstlogin to 
!!  offer the users a choice of the sessions available on the system.

Dtlogin\*fallbackDt:	/usr/dt/config/Xsession.jds

------------------------------------------------------------------------------


Imported interfaces:

dtlogin lastsession mechanism		Project Private	ASARC/1995/390
/usr/dt/bin/sdt_firstlogin		Project Private	ASARC/1995/390

Exported interfaces:

Dtlogin\*defaultDt resource		Stable
Dtlogin\*fallbackDt resource		Stable

Default settings of new resources	Volatile

By declaring these Stable, we're promising that these resources will take values as described and do what we say until further notice. It doesn't prevent us from further changing or refining this in the future (though since we're really trying to replace dtlogin with gdm in the future, we're not likely to do much), it just means that if we do, we'll have to either change these in a compatible way or create new resources. By declaring the defaults as Volatile though, we're warning that we could change them at any time, without warning - for now they're the Xsession file currently used by JDS, but we could change to another mechanism of starting JDS or even (though highly unlikely) to another desktop altogether, without having to worry about having made any compatibility guarantee there.

The note about a “Patch release binding” indicates that we think these changes are compatible enough with current systems to allow shipping this change in a patch or update release (and in fact, this change is being backported to a Solaris 10 patch to be included in the third Solaris 10 update release, tentatively scheduled for release near the end of this year). These changes don't break any existing systems, don't change anything for existing users with a valid desktop choice, still give new users a choice of desktops, and can even be easily overridden by sysadmins who still really prefer their new users be suggested CDE instead of the newer, easier-to-use GNOME-based JDS desktop.

A lot of people think that binary compatibility guarantees that Solaris provides stifle innovation because we can never change things - this is an example of why that's not the case. We don't guarantee nothing about the system will ever change - that would be foolish - what we do is specify what things you can count on remaining compatible (not unchanged, just compatible), and what you can't - and how long that compatibility is promised for. We've never made any promises in the past about what choice would be shown as the default in the session choice dialog, and the Volatile stability for this reflects that we still aren't - but because that's not someting that affects the managability of Solaris systems or the ability of ISV's to provide applications, it's not something we need to make those sort of promises about. The new resources are declared Stable because we don't want admins to use them and then find when they upgrade to a future release that we've broken their settings or made it so their users can't login until they find and fix the problem.

Right now these promises are mostly expressed via the man pages in Solaris - especially the Attributes section in many man pages. The ARC team is also working to open up the processes through which these are set and the history of many of the past review cases that set important ones, via the OpenSolaris ARC community, so that developers will have greater insight into these compatibility promises and eventually even have a voice in shaping them.

[Technorati Tags: , , , ]

Wednesday Oct 27, 2004

"You sunk my battleship grey!"

I sometimes wonder how many people will really see the effects of work I do in Solaris. Some fixes I know only a handful of people will ever notice since they're in such corner cases. In this month's Solaris Express/Solaris 10 Beta 7 build though, I know a change I made will be seen by every Solaris desktop user as soon as they finish installing, and it may be the most visible change I've ever made to Solaris. (That's almost a bit scary...)

Alan DuBoff already wrote about the new splash screens in this release, but didn't quite capture the entire depth of the change - it's more than just updating the splash screens as we've done with every previous Solaris release - the whole login screen got a makeover as well. The original directive that kicked off this project was a missive from above to "Get rid of the battleship grey, and make it look modern, not like a holdover from the 80's." (Not an exact quote I'm sure, since it filtered through a few people before it got to me, and my memory is far from perfect.) The image to a right is just a clip - click on it for a full screenshot to see its full glory. That's still the same CDE dtlogin program we've shipped in Solaris for almost a decade now, just with some changes to the X resources to change the appearance - you can still see hints of the old login screen in things like the buttons. Sun's Software Experience Design team did the hard part - coming up with the new design and graphics - I just had to do a little work in dtlogin to implement their design.

Under the hood, the only code changes were to stop hardcoding some of the resources and allow the Xresources file to override them. The X resources file was then modified to include a new file called styleModern - since it's run through the C pre-processor first, this was simply adding a #include line for it and setting the include path to search. The first attempt discovered that Motif does not handle well XPM files with thousands of colors - my Ultra 10 test machine took 30 seconds to load the login screen. Fortunately our graphics designers were able to reduce the number of colors used without making the graphics ugly, and it now takes no more time than the original login screen did to come up.

So far, most of the feedback I've seen from our internal testers has been very positive of the new look, and with the imminent release of Solaris 10 Beta 7 and the Solaris Express 10/04 release, we'll be putting out for everyone to see. Of course, some people don't like change - they may have customized the look of the old login screen to be just the way they want, and for them, the old screen is easy to restore - since it's created by loading the new X resource values in the styleModern file, removing the include from the Xresources file will restore the old look, as will simply making it find an empty styleModern in the include path ahead of the real one (such as by running "mkdir -p /etc/dt/config/C ; touch /etc/dt/config/C/styleModern")

Unfortunately, most locales have their own versions of this file in order to translate all the buttons and menus, and they were not all updated in time for this month's beta/express release, so you may have to choose 'C' or another English locale to see the new look - the localization teams are working on getting the other locales in sync for the final release of Solaris 10. Also, this was only done to dtlogin, which is still the default login screen in Solaris 10 - gdm2 is also available now that the Java Desktop System is included, but it already has it's own modern look-and-feel.

Oh, and don't get too attached to this particular set of colors & graphics - they're a placeholder to get the integration with dtlogin done and tested in the beta release - the final Solaris 10 graphics are still to come...

[See more blogs and links on Solaris at ]

Monday Jul 19, 2004

Followup notes on Solaris wheel mouse support

Jürgen Keil pointed out on the Solaris x86 mailing list that the wheelmaps syntax I covered earlier works with his driver as well and that you may need to override the number of buttons set by kdmconfig on Solaris x86 for certain customizations.

Someone posting as "fogh" on comp.unix.cde provided wheel mouse bindings for CDE's dtwm window manager. I never thought of using the mouse wheel to change workspaces, but that seems like a cool use of it.

Thursday Jul 15, 2004

Wheel Mouse support for Solaris: Part 2: Using it with applications

The default configuration of the wheel mouse support in Solaris (both the new support for workstations in my previous post and the existing support in the Sun Ray 2.0 software) is to map the wheel rolls to presses of buttons 4 & 5, as done in XFree86 and other X servers. Because of this, software written to support scroll wheels in those other servers often just starts working on Solaris as soon as you install the wheel mouse support, and much other software can be easily configured to do so as well. Software that should just work includes GNOME 2.0 and other software using the GTK+ toolkit, Mozilla, Netscape 7.0, and StarOffice 7. The Xsun patch for Solaris 9 that introduces workstation wheel mouse support also includes an update to the Solaris xterm to support scroll wheels as well.

There's an existing site with tips for many applications, including older versions of Netscape, at http://koala.ilog.fr/colas/mouse-wheel-scroll/.

Additionally, you can add scroll wheel support to some of the existing CDE & X applications on Solaris by adding entries to your $HOME/.Xdefaults file such as these:

\*DtTerm\*Translations: #override \\
        Shift<Btn4Down>:        scroll(-1,page) \\n\\
        Shift<Btn5Down>:        scroll(1,page) \\n\\
        None<Btn4Down>:         scroll(-5,line) \\n\\
        None<Btn5Down>:         scroll(5,line)

\*DtEditor.textTranslations: #override \\
        Shift<Btn4Down>:        previous-page() \\n\\
        Shift<Btn5Down>:        next-page() \\n\\
        None<Btn4Down>:        process-up()process-up()process-up()process-up()process-up() \\n\\
        None<Btn5Down>:        process-down()process-down()process-down()process-down()process-down()

\*DtHelpDialog\*textTranslations: \\
           <Btn4Down>:	       PageUpOrDown(1)\\n\\
           <Btn5Down>:	       PageUpOrDown(0)

Xman\*help\*Paned.manualPage.translations:#override \\
				<Key>Prior: Page(Back) \\n\\
				<Key>Next : Page(Forward)  \\n\\
      				Shift<Btn4Down>,<Btn4Up>: Page(Line,-1) \\n\\
			        Shift<Btn5Down>,<Btn5Up>: Page(Line,1) \\n\\
			        Ctrl<Btn4Down>,<Btn4Up>: Page(Back) \\n\\
				Ctrl<Btn5Down>,<Btn5Up>: Page(Forward) \\n\\
				None<Btn4Down>,<Btn4Up>: Page(Line,-5) \\n\\
				None<Btn5Down>,<Btn5Up>: Page(Line,5)

Xman\*manualBrowser\*manualPage.translations:  #override \\
				<Key>Prior: Page(Back) \\n\\
				<Key>Next : Page(Forward) \\n\\
				Ctrl<Key>s: PopupSearch() \\n\\
      				Shift<Btn4Down>,<Btn4Up>: Page(Line,-1) \\n\\
			        Shift<Btn5Down>,<Btn5Up>: Page(Line,1) \\n\\
			        Ctrl<Btn4Down>,<Btn4Up>: Page(Back) \\n\\
				Ctrl<Btn5Down>,<Btn5Up>: Page(Forward) \\n\\
				None<Btn4Down>,<Btn4Up>: Page(Line,-5) \\n\\
				None<Btn5Down>,<Btn5Up>: Page(Line,5)

(You won't need any of these entries on Solaris Express 5/04 and later, or Solaris 10, since they're already included in the default X resource sets for those applications in those releases. You can add them though if you want to customize the rates at which the wheel scrolls the text in those applications, or mappings of the modifier keys to effects.)

About

Engineer working on Oracle Solaris and with the X.Org open source community.

Disclaimer

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle, the X.Org Foundation, or anyone else.

See Also
Follow me on twitter

Search

Categories
Archives
« July 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today