[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: is xaw3d still necessary?



>>>>> Bernhard R Link <brlink@debian.org> writes:

 >> Now that Xaw3d has not seen a release in five years [1], and as Xaw
 >> allows for even more slicky UI (and seems to be still maintained
 >> upstream), couldn't the xaw3d package be removed and all the
 >> packages depending on it switched to use Xaw instead?

 > Do you have some documentation about porting programs from xaw3d to
 > Xaw?  (ideally without too large changes in the UI).

	No.  May be I'll find some time to port a package or two and
	then post the bits of my experience.

 > While some programs once were able to use both, many use some of the
 > advanced features of xaw3d.

	Actually, I don't see ``many'' packages depending on xaw3dg in
	etch:

$ apt-cache showpkg xaw3dg 
...
  xvkbd,xaw3dg 1.5+E-1
  xruskb,xaw3dg 1.5+E-1
  xrn,xaw3dg 1.5+E-1
  xpaint,xaw3dg 1.5+E-1
  xfrisk,xaw3dg 1.5+E-1
  xfm,xaw3dg 1.5+E-1
  xfig,xaw3dg 1.5+E-1
  xcolorsel,xaw3dg 1.5+E-1
  xbvl,xaw3dg 1.5+E-1
  xboard,xaw3dg 1.5+E-1
  xaw3dg-dev,xaw3dg 1.3-6.4
  xaw3dg-dev,xaw3dg 1.5+E-14
  isdnbutton,xaw3dg 1.5+E-1
  gv,xaw3dg 1.5+E-1
  freeciv-client-xaw3d,xaw3dg 1.5+E-1
  emacs21,xaw3dg 1.5+E-1
  3dchess,xaw3dg 1.5+E-1
...
$ 

 > And I've not yet seen more than allegations that the 3d look and feel
 > is easily possible with Xaw.

	It depends on what to call ``easy''.  At least, the Xmessage's
	`-color' app-defaults file:

/etc/X11/app-defaults/Xmessage-color

	doesn't look too complicated (two identical `displayList's to
	make `Scrollbar' and `Text' widgets look sunken, and two more
	identical `displayList's to make `Command' and `Form' look
	risen.)

 > (I guess most importantly scroll bars, most young people nowadays
 > have no clue how to use the left-click-right-click Xaw scrollbars).

	I guess that this part may take up a bit of digging into the
	recent Xaw (or Xt?) features.

	FWIW, editres does this bit with `MenuButton's:

--cut: Editres-color--
*MenuButton.translations:	\
<Enter>:	set-values(1, background, "rgb:29/44/94", borderColor, "rgb:1d/30/69", displayList, "foreground rgb:20/35/73;lines 1,-1,-1,-1,-1,1;foreground rgb:30/4e/ab;lines -1,0,0,0,0,-1")\n\
<Leave>:	set-values(1, background, RoyalBlue4, borderColor, RoyalBlue4, displayList, "")\n\
Any<BtnDown>:	set-values(1, background, "rgb:23/3a/7d", displayList, "foreground rgb:30/4e/ab;lines 1,-1,-1,-1,-1,1;foreground rgb:20/35/73;lines -1,0,0,0,0,-1") PopupMenu()
--cut: Editres-color--

	And scroll bars apparently get these translations by default:

<Btn1Down>:StartScroll(Forward)
<Btn2Down>:StartScroll(Continuous) MoveThumb() NotifyThumb()
<Btn3Down>:StartScroll(Backward)
<Btn2Motion>:MoveThumb() NotifyThumb()
<BtnUp>:NotifyScroll(Proportional) EndScroll()

	Couldn't these be rewritten to decide the scroll type based on
	the pointer position and not the button being pressed?

 > Xaw3d really needs some love (it seems to have been forged off Xaw
 > before that was extended to support prototypes for example), and a
 > sane and doable way to replace it with Xaw while still looking and
 > behaving the same would be very welcome, but even if it was possible
 > I guess it would need many years as not many people know Xt

	Mimicking Xaw3d behaviour in Xaw programs shouldn't require any
	programming at all (except for, perhaps, patching Xaw to support
	some features, though I'd hope that all the really necessary
	ones are already there.)

	Moreover, I don't think that making Xaw versions look and behave
	indistinguishable from their Xaw3d counterparts is worth all the
	unreasonable efforts it may take.

	BTW, what are the features of Xaw3d which aren't that of a Xaw?
	So far, I've seen the ``blocky'' 3D widgets' ``borders'' and the
	scroll bars.  Are there others?

 > (and even less people know it proper, so most Xt using programs
 > already only support a minor subset of its capabilities, making
 > porting much harder).

 >> This would solve Bug#329987 in particular.

 > As this only requests an Xaw version, this bug does not need xaw3d to
 > be removed to implement that one...

	Yes.


Reply to: