Re: Xfce for cygwin
David Fraser wrote:
Mark Fisher wrote:
I've just ported xfce4.2 to cygwin, and start it like this:
Fantastic! Are the patches included in the CVS, are their any particular
build instructions?
I'm on the xfce dev list but I didn't see anything about this ...
The patches are in CVS (I was the one who committed them), and there are
specific built instructions.
You need to get libdbh and libstartup-notification yourself, and I'm
using the attached script to build XFCE. Haven't tried this in some time
though due to work load, so I can't guarantee everything still works
out-of-the-box. And oh yeah, you need a very recent version of libtool.
As I just wrote to Mark:
"Anyways, you do know that there is a couple of things that do not work
in XFCE for cygwin, right? For one, panel plugins are not fully
functional (just try to change the icon size in the panel and see what
happens). Also, xffm doesn't work, neither is xfprint (I've never really
tried this though), and xfce4-mixer.
The problem with the panel plugins and xffm is that XFCE is coded such
that the plugins must access variables in the loading program, and
MS-Windows (and therefore cygwin) doesn't allow this. I've had some
discussion with Jasper from the XFCE team about this, and we were
thinking of a complete rewrite of the XFCE plugin system. However, this
will have to wait until the 4.2 release, and I'm completely swamped in
work at the moment..."
Maarten
#!/bin/bash
cvs_dir=/e/Maarten/src/xfce
log_dir=/e/Maarten/src/xfce/complogs
install_dir=/opt/xfce
# SET REQUIRED PKG_CONFIG DIRECTORIES
PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH
PKG_CONFIG_PATH=${cvs_dir}/xfce4/xfce4-panel/panel:$PKG_CONFIG_PATH
PKG_CONFIG_PATH=${cvs_dir}/xfce4/libxfcegui4/libxfcegui4:$PKG_CONFIG_PATH
PKG_CONFIG_PATH=${cvs_dir}/xfce4/libxfce4util/libxfce4util:$PKG_CONFIG_PATH
PKG_CONFIG_PATH=${cvs_dir}/xfce4/libxfce4mcs/libxfce4mcs:$PKG_CONFIG_PATH
PKG_CONFIG_PATH=${cvs_dir}/xfce4/xfce-mcs-manager/xfce-mcs-manager:$PKG_CONFIG_PATH
PKG_CONFIG_PATH=${cvs_dir}/xfce4/xffm/src:$PKG_CONFIG_PATH
PKG_CONFIG_PATH=${cvs_dir}/xfce4/xfce4-session/xfce4-session:$PKG_CONFIG_PATH
export PKG_CONFIG_PATH
export ACLOCAL_FLAGS="--force"
usage() {
echo "Usage: $0"
echo " --help or -hdisplay this message"
echo " --clean remove the old installation"
echo " --make-cleando a 'make clean'"
echo " --install do a 'make install'"
}
apkg() {
if [ -z "$PKGS" ]
then
PKGS=$1
else
PKGS="${PKGS} $1"
fi
}
apkg xfce4/libxfce4util:--prefix=${install_dir}
apkg xfce4/libxfcegui4:--prefix=${install_dir}
apkg xfce4/libxfce4mcs:--prefix=${install_dir}
apkg xfce4/xfce-mcs-manager:--prefix=${install_dir}
apkg xfce4/xfcalendar:--prefix=${install_dir}
apkg xfce4/xfce4-panel:--prefix=${install_dir}
apkg xfce4/gtk-xfce-engine-2:--prefix=${install_dir}
apkg xfce4/xfce-utils:--prefix=${install_dir}
apkg xfce4/xfwm4:--prefix=${install_dir}
apkg xfce4/xfwm4-themes:--prefix=${install_dir}
apkg xfce4/xfdesktop:--prefix=${install_dir}
apkg xfce4/xfce-mcs-plugins:--prefix=${install_dir}
apkg xfce4/xfce4-appfinder:--prefix=${install_dir}
apkg xfce4/xfce4-session:--prefix=${install_dir}
apkg xfce4/xfce4-icon-theme:--prefix=${install_dir}
apkg xfce4/xfce4-iconbox:--prefix=${install_dir}
apkg xfce4/xfce4-systray:--prefix=${install_dir}
apkg xfce4/xfce4-toys:--prefix=${install_dir}
apkg xfce4/xfce4-trigger-launcher:--prefix=${install_dir}
#apkg xfce4/xffm:--prefix=${install_dir}
#apkg xfce4/xfce4-mixer:--prefix=${install_dir}
#apkg xfce4/xfprint:--prefix=${install_dir}
#apkg xfce4/xfce4-terminal:--prefix=${install_dir}
error=0
clean=0
make_cmd="make"
help=0
while [ $# != 0 ]
do
case "$1" in
'--help')
help=1
shift
;;
'-h')
help=1
shift
;;
'--clean')
clean=1
shift
;;
'--make-clean')
make_cmd="make clean && ${make_cmd}"
shift
;;
'--install')
make_cmd="${make_cmd} && make install"
shift
;;
*)
echo "Unknown option: $1"
error=1
shift
;;
esac
done
if [ $help -eq 1 ]; then
usage
exit 1
fi
if [ $error -eq 1 ]; then
usage
exit 1
fi
if [ $clean -eq 1 ]; then
echo -n "Removing old installation from ${install_dir}... "
rm -rf ${install_dir} > /dev/null 2>&1
echo "Done"
fi
rm -rf ${log_dir}/* > /dev/null 2>&1
if [ ! -d ${log_dir} ]
then
mkdir ${log_dir}
fi
for i in ${PKGS}
do
pkg=`echo $i | cut -d: -f1`
options=`echo $i | cut -s -d: -f2- | sed -e 's/:/ /'`
log=${log_dir}/`basename ${pkg}`.log
echo "Installing \"${pkg}\" with \"${options}\""
cd ${cvs_dir}/$pkg
./autogen.sh ${options} | tee ${log} 2>&1
$SHELL -c "${make_cmd}" | tee -a ${log} 2>&1
#$("${make_cmd}") | tee -a ${log} 2>&1
done
Xfce for cygwin
Mark Fisher wrote: I've just ported xfce4.2 to cygwin, and start it like this: Fantastic! Are the patches included in the CVS, are their any particular build instructions? I'm on the xfce dev list but I didn't see anything about this ... David
Re: Starting X on a second monitor - kludge that works
Howdy... At 05:38 PM 12/1/2004 +, Mark Fisher wrote: I've been trawling the archives looking for a solution to the problem of starting Xwin on a second monitor. The only way I've been able to get this to work is to use a program that allows you to send the app to a 2nd monitor. The program in question is UltraMon. If your second monitor is a different size to your primary, then no fear, just specify the size of the screen when starting x. I've just ported xfce4.2 to cygwin, and start it like this: bash --login -c "/opt/xfce4/bin/startxfce4 -- -nodecoration -screen 0 1280 1024" I'm not familiar with xfce, but why not just add a "-position x y" option to XWin.exe such that when present and in a root-window mode it'll move the created window to whatever screen you want (via the absolute Windoze X/Y position)? That's all the UltraMon app is doing... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Internal-wm/rootless observations
On Wed, 1 Dec 2004, Torrey Lyons wrote: > I have been away on a long Thanksgiving vacation so I've been slow to > respond. No problem. I'm hunting this for some weeks already > In any case, the 16 bpp modes are problematic but I believe > we solved issues with them in the rootless code awhile back. The > fundamental problem is that fb assumes screens are always 32-bit > aligned. Thus you if a window's pixmap is not 32-bit aligned, fb > assumes it can still access the word before the start of a drawable's > data. In rootless mode, where windows are located higgledy-piggledy > in memory, this is not true. > > Rootless solves (or attempts to solve) this problem with the > SetPixmapBaseToScreen() macro in rootlessCommon.h. The idea is that > the unaligned window's pixmap is moved backwards in memory to align > it and then a positive offset it given to fb to indicate where the > window resides in the pixmap. > > If there is an edge case where rootless does not work in 16-bits it > would be good to track down. This mode is sometimes used on Mac OS X. Maybe the odd window width is the problem. Testcase: xterm width 501 pixel http://www-user.tu-chemnitz.de/~goal/Xming/internalwm.png setting the with to 502 pixel in the debugger solved the distorted drawing. assuming the base was 0x2b0. After the window was translated by (0,5) the pixmap base was moved by 5 * 1002 bytes. In the fb drawing functions the offset was never correct to 0x2b0. It was still below that value and the access an access violation. I had problems with fbCopyNtoN and fbBlt. SetPixmapBaseToScreen does: ptr = 0x2b0 - 5 * 1002 = 0x2afec6e This is unaligned -> fixing this ptr = 0x2afec6e - 2 = 0x2afec6c fbCopyNtoN does dst + (pbox->y1 + dstYoff) * dstStride so this is 0x2afec6c + (0 + 5) * 1002 = 0x2ae -> unaligned and _off pixmap_ bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Starting X on a second monitor - kludge that works
Hi. I've been trawling the archives looking for a solution to the problem of starting Xwin on a second monitor. The only way I've been able to get this to work is to use a program that allows you to send the app to a 2nd monitor. The program in question is UltraMon. If your second monitor is a different size to your primary, then no fear, just specify the size of the screen when starting x. I've just ported xfce4.2 to cygwin, and start it like this: bash --login -c "/opt/xfce4/bin/startxfce4 -- -nodecoration -screen 0 1280 1024" (this I run as a batch file using either the /usr/X11R6/bin/run to hide the window, or a free program I found called "runhide") which opens then screen at my 2nd monitor's resolution (but on the primary monitor), then on the task bar, RMB on the app, choose "Move to other monitor". For those of you fortunate enough to have a radeon gfx card (my last job used dell's with radeon cards), then the native gfx drivers allow this kind of functionality too. anyone found another method for doing this? I quite like XFCE on my 2nd monitor. Now to port firefox using gtk under cygwin... Mark Fisher
Re: Internal-wm/rootless observations
I have been away on a long Thanksgiving vacation so I've been slow to respond. In any case, the 16 bpp modes are problematic but I believe we solved issues with them in the rootless code awhile back. The fundamental problem is that fb assumes screens are always 32-bit aligned. Thus you if a window's pixmap is not 32-bit aligned, fb assumes it can still access the word before the start of a drawable's data. In rootless mode, where windows are located higgledy-piggledy in memory, this is not true. Rootless solves (or attempts to solve) this problem with the SetPixmapBaseToScreen() macro in rootlessCommon.h. The idea is that the unaligned window's pixmap is moved backwards in memory to align it and then a positive offset it given to fb to indicate where the window resides in the pixmap. If there is an edge case where rootless does not work in 16-bits it would be good to track down. This mode is sometimes used on Mac OS X. Hopefully that is helpful. I've got a review today but I can look at this in more detail tomorrow. --Torrey At 4:45 PM +0100 11/30/04, Alexander Gottwald wrote: Hi all, After many days of debugging the internalwm code i finally found the actual problem. The rootless code wants the pixmap buffer aligned to 32bit boundaries. If the window width is odd and the xserver is run in 16bpp mode then this is no guaranteed and this leads the strange errors. Internalwm is only usable in 32bit mode. This is not an actual problem. The goal should be anyway to work with 32 bit visuals only and have real transparancy. I'm still searching for a clean method to blit 32 bit bitmaps to 16 bit ones. The simple aproach of allocating the bitmap with CreateCompatibleBitmap() bitmap->width = width bitmap->height = height bitmap->bpp = dbBPP CreateDIBSection() BitBlt(windowdc, ..., shadowdc, ...) was not working properly. Is CreateCompatibleBitmap reusing the DC from the screen? How can I create a 32bit bitmap if the desktop is running in 16bit? Anyway. Setting the bitmap depth to 32bit fixed the crashes I had the last weeks with rootless but garbled the output. So the goal is to have everything inside the server running at 32bit and let GDI do the colorspace translation from 32 to 16 or 24 bit. @zakki: I've found this in the code if (winIsInternalWMRunning(pScreenInfo)) winAdjustXWindow (pWin, hwnd); winMWExtWMMoveResizeXWindow (pWin, shouldn't that be if (winIsInternalWMRunning(pScreenInfo)) winAdjustXWindow (pWin, hwnd); else winMWExtWMMoveResizeXWindow (pWin, bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Problems building X/Cygwin (no XpConfig)
--- Christopher Faylor <[EMAIL PROTECTED]> wrote: > > Alexander, I think you need another support > category: > > totally clueless : $1000 nope it should be totally clueless : priceless
Re: Problems building X/Cygwin (no XpConfig)
On Wed, Dec 01, 2004 at 07:04:16PM +0300, Igor Shmukler wrote: >Is your mother proud of your manners? You have got to be kidding me! You wonder into this mailing list firing off content-free criticisms and tell everyone to go to a competing commercial product. And, *you* are talking about *manners*? Alexander, I think you need another support category: totally clueless : $1000 cgf
Re: Problems building X/Cygwin (no XpConfig)
On Wed, Dec 01, 2004 at 04:36:08PM +0100, Alexander Gottwald wrote: >Hm. Maybe I should put a sign on the website: > >+--+ >| Mailinglist support fees | >+--+ >| | >| regular users: free | >| dumb-asses:$1| >| assholes: $10 | >+--+ > LOL! You can take comfort in the fact that you've actually accomplished something constructive with your life that has benefitted many people. Contrast that with the "documentation sucks" people and the people who think that they help by sending cliche-ridden manifestos about the way things ought-to-be done. Even if the documentation did suck and even if the project was horribly managed (both false premises) you can claim satisfaction in the fact that you are actively doing something which is demonstrably helping many people. The critics, no matter how articulate they are (I'm sure there must be at least one articulate critic out there although we haven't seen one here in a while) usually do very little to help. In a free software project, there really is little excuse for someone taking twenty minutes to write a message when they could have spent twenty minutes improving documentation or fixing code instead. cgf
Re[3]: Problems building X/Cygwin (no XpConfig)
Is your mother proud of your manners? > > Alex, > > > > I actually went to X.org and got latest release of X. > > IMHO, cygwin documentation sucks. Same goes for the setup tool and > > packaging. At least DLL still works. If maintainers (are there such > > individuals?) want to know how these things can be done, I suggest looking > > at FreeBSD ports. > > > > Building an entire environment from scratch is way easier. UWIN that I used > > several years ago, is nice but not free for commercial use. If you do not > > need to bother with commercial use I suggest trying UWIN ASAP. > > yet another blurb. > > How much have you paid for cygwin? Nothing? You get what you've paid for? > > No. Actually you get far more than that. But it does not seem to bother > you. > > Hm. Maybe I should put a sign on the website: > > +--+ > | Mailinglist support fees | > | | > | regular users: free | > | dumb-asses:$1| > | assholes: $10 | > +--+ > > http://x.cygwin.com/donations.html > > @ьyvind: Just what I've ranted about in yesterdays mail. > > bye > ago > -- > [EMAIL PROTECTED] > http://www.gotti.org ICQ: 126018723 >
Re: Problems building X/Cygwin (no XpConfig)
On Wed, Dec 01, 2004 at 06:13:46PM +0300, Igor Shmukler wrote: >I actually went to X.org and got latest release of X. IMHO, cygwin >documentation sucks. Comments like "documentation sucks" are completely useless and obviously intended to make the sender feel self-righteous and irritate the people who are working on the project. This is not an "IMHO". It is a fact. Anyone with any background in software, and particularly in free software, would know that the documentation is improved either by offering specific comments or, even better, by offering actual words to improve it. Inflammatory words like "sucks" do absolutely nothing towards improving anything and just illustrate the senders unhelpful mindset. I say this, knowing full well that this email will probably be followed by point-missers saying "But, the documentation *is* bad! *sob* I can't figure it out, so it *must* be bad." or "You should listen to the users! The users! *sob*" The rest of this message just continued in kind so, rather than repeatedly make the same points, I will stop here. cgf
Re[2]: Problems building X/Cygwin (no XpConfig)
On Wed, 1 Dec 2004, Igor Shmukler wrote: > Alex, > > I actually went to X.org and got latest release of X. > IMHO, cygwin documentation sucks. Same goes for the setup tool and packaging. > At least DLL still works. If maintainers (are there such individuals?) want > to know how these things can be done, I suggest looking at FreeBSD ports. > > Building an entire environment from scratch is way easier. UWIN that I used > several years ago, is nice but not free for commercial use. If you do not > need to bother with commercial use I suggest trying UWIN ASAP. yet another blurb. How much have you paid for cygwin? Nothing? You get what you've paid for? No. Actually you get far more than that. But it does not seem to bother you. Hm. Maybe I should put a sign on the website: +--+ | Mailinglist support fees | | | | regular users: free | | dumb-asses:$1| | assholes: $10 | +--+ http://x.cygwin.com/donations.html @Øyvind: Just what I've ranted about in yesterdays mail. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re[2]: Problems building X/Cygwin (no XpConfig)
Alex, I actually went to X.org and got latest release of X. IMHO, cygwin documentation sucks. Same goes for the setup tool and packaging. At least DLL still works. If maintainers (are there such individuals?) want to know how these things can be done, I suggest looking at FreeBSD ports. Building an entire environment from scratch is way easier. UWIN that I used several years ago, is nice but not free for commercial use. If you do not need to bother with commercial use I suggest trying UWIN ASAP. Igor. -Original Message- From: Alexander Gottwald <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], Igor Shmukler <[EMAIL PROTECTED]> Date: Wed, 1 Dec 2004 01:43:22 +0100 (MET) Subject: Re: Problems building X/Cygwin (no XpConfig) > > Igor Shmukler wrote: > > > Hello, > > > > I am trying to build X/Cygwin. > > I installed the tools and used setup program to checkout the sources. > > For some reason programs/Xserver/ directory does not have XpConfig branch. > > I tried checking out from several alternative locations. > > Build compains that the directory is missing and stops. X.org repository > > indeed does have the directory. > > > > Any ideas? > > have you tried cvs update -d? This creates missing directories. > > Which command did you use? > > bye > ago > NP: Iris - Whatever > -- > [EMAIL PROTECTED] > http://www.gotti.org ICQ: 126018723 >
Re: Cygwin X live on CD
On Wed, 1 Dec 2004, Dick Repasky wrote: > > I've built a CD-ROM that runs Cygwin X live from CD in a modest Cygwin > environment. It's available at http://xlivecd.indiana.edu/. > > Briefly, I was messing around to build Cygwin on a USB flash drive and > posted to the Cygwin mailing list. Fergus pointed out his instructions > for building a Cygwin CD. I realized that we have users who could really > use Cygwin X on CD so I applied Fergus' instructions, made some > modifications, and added a wizard to give the CD the feel of an > application that has the sole purpose of running X. The scripts that I > wrote to make the wizard work are under the GPL. Nice to hear. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Internal-wm/rootless observations
On Wed, 1 Dec 2004, Kensuke Matsuzaki wrote: > Could you give me diff? I want to try that. Actually not. Most changes where done in gdb with "set var " ;) let's do it from memory: in winMWExtWMStartDrawing: hdcNew = CreateCompatibleDC (pRLWinPriv->hdcScreen); /* Describe shadow bitmap to be created */ pRLWinPriv->pbmihShadow->biWidth = pRLWinPriv->pFrame->width;//pRLWinPriv->dwWidth; pRLWinPriv->pbmihShadow->biHeight = -pRLWinPriv->pFrame->height;//pRLWinPriv->dwHeight; + pRLWinPriv->pbmihShadow->biBitCount = 32; /* Create a DI shadow bitmap with a bit pointer */ in winAdjust - /* Query GDI for current display depth */ - dwBPP = GetDeviceCaps (hdc, BITSPIXEL); + /* Set the colordepth to 32 to please rootless code */ + dwBPP = 32; /* GDI cannot change the screen depth */ This is in no way safe and should be wrapped with a check for -internalwm but safe for testing > I think we have no reason to use winshadgdi.c in mwextwm mode and some > code in winshadgdi.c don't match mwextwm. I have to write winshadrootless? I don't think so. We have way too much code anyway i think. 5 different engines, to code for handling windowed, pseudorootless and rootless code. If we find a safe way to blit from 32bit planes to 16bit planes then this will be quite useful in shadow GDI mode too. Sebastian Haby told me the 8bit pseudocolor patch he made has similar code (blitting from a 8bit plane to 32/24/16 bit). I'll have to check the mail archives at home for this code bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Cygwin X live on CD
I've built a CD-ROM that runs Cygwin X live from CD in a modest Cygwin environment. It's available at http://xlivecd.indiana.edu/. Briefly, I was messing around to build Cygwin on a USB flash drive and posted to the Cygwin mailing list. Fergus pointed out his instructions for building a Cygwin CD. I realized that we have users who could really use Cygwin X on CD so I applied Fergus' instructions, made some modifications, and added a wizard to give the CD the feel of an application that has the sole purpose of running X. The scripts that I wrote to make the wizard work are under the GPL. Enjoy, Dick - Dick Repasky Bioinformatics Support UITS Cubicle 101.08 Indiana University USA [EMAIL PROTECTED]
Re: Internal-wm/rootless observations
> After many days of debugging the internalwm code i finally found > the actual problem. > > The rootless code wants the pixmap buffer aligned to 32bit boundaries. > If the window width is odd and the xserver is run in 16bpp mode then > this is no guaranteed and this leads the strange errors. > > Internalwm is only usable in 32bit mode. I can reproduce the problem when I change 16bit mode. Usually I use 32bit mode, so I couldn't. > This is not an actual problem. The goal should be anyway to work > with 32 bit visuals only and have real transparancy. I'm still > searching for a clean method to blit 32 bit bitmaps to 16 bit ones. > The simple aproach of allocating the bitmap with Could you give me diff? I want to try that. I think we have no reason to use winshadgdi.c in mwextwm mode and some code in winshadgdi.c don't match mwextwm. I have to write winshadrootless? Thanks in advance. -- Kensuke Matsuzaki mailto:[EMAIL PROTECTED] http://peppermint.jp
