neditc (renamed from nc to avoid confusion) should open files on existing nedit servers, created by running 'nedit -server'. However, 'neditc doc.ext' creates its own server, then opens another window managed by the new server to display doc.ext. Client/server communication can be demonstrated by using named servers ('nedit -server -svrname test' followed by 'neditc -svrname test doc.ext'), however, the document is opened in a new window, even if the -tabbed option is passed to neditc. Reproducible: Always Steps to Reproduce: 1.from xterm: nedit -server -svrname test & 2.from xterm: neditc -tabbed /etc/hosts 3.from xterm: neditc -svrname test -tabbed /etc/hosts Actual Results: 4 nedit windows are created: step 1:'test' server window with blank document step 2:unnamed server window with blank document and unnamed server window with /etc/hosts step 3.'test' server window with /etc/hosts ps -u confirms that only two nedit processes are running - 'nedit -server -svrname test' and 'nedit -server' Expected Results: step 1:open a nedit 'test' server window with a blank document step 2:open a new tab in existing window containing /etc/hosts step 3:open another new tab in existing window containing /etc/hosts AMD64, 1GB RAM, nVidia 6600GT, 2.6.10 kernel (vanilla sources), fluxbox wm
Amendment: the client is connecting to the server now, and I can't reproduce the original behavior in which the client started an additional server. I haven't changed configuration, so the bug is either intermittent or due to user error. However, the server still does not honor the -tabbed option. I have tracked down the cause for this behavior somewhat - the nedit server iterates over it's list of open windows, looking for one on the desktop from which the client request originated. It does this by checking the _NET_WM_DESKTOP window property, but on my system, windows (from any application) do not initially have this property. (If a window is moved to another desktop, it acquires the _NET_WM_DESKTOP property, and if a client request is made from the new desktop, the -tabbed option is honored, and everything works as it should). Since the property does not exist, the server exhausts the list of windows, finds no match, and opens a new window. I don't know enough about X programming to know if the bug is in nedit, my window manager (fluxbox), or X. Also, this bug may be present in 32-bit systems, although it is masked by another subtle bug: the server also looks for sticky windows, which would have a _NET_WM_DESKTOP of 0xFFFFFFFF, which, on a 32-bit system, is equal to the error value (-1) returned if the _NET_WM_DESKTOP property is not found. This behavior would manifest itself on 32-bit systems by servers opening tabs in existing windows on any desktop, regardless of which desktop the client request came from. The return type in question is a long int, which is 64 bits on amd64, and 0x00000000FFFFFFFF != -1, so windows are not erroneously identified as sticky. Gentoo Base System version 1.6.12 Portage 2.0.51.19 (default-linux/amd64/2005.0, gcc-3.4.3, glibc-2.3.4.20041102-r1, 2.6.10-test x86_64) ================================================================= System uname: 2.6.10-test x86_64 AMD Athlon(tm) 64 Processor 3000+ Python: dev-lang/python-2.3.5 [2.3.5 (#1, May 11 2005, 22:30:02)] dev-lang/python: 2.3.5 sys-apps/sandbox: [Not Present] sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.7.9-r1, 1.5, 1.6.3, 1.4_p6, 1.9.5, 1.8.5-r3 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.8.1-r4 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.chem.wisc.edu/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X acpi alsa berkdb bitmap-fonts crypt curl flac font-server fortran gif gpm gtk guile ipv6 jp2 jpeg lzw lzw-tiff motif mp3 ncurses nls ogg opengl pam perl png postgres python readline ssl tcpd tiff truetype truetype-fonts type1-fonts usb userlocales vorbis xml2 xmms xpm xrandr xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
Looks like the _NET_WM_DESKTOP property is the responsibility of the window manager, making this a fluxbox bug.
