Re: Icon update .diff
Hi, Belatedly found an error in Joe's icon_and_class.diff patch:- http://cygwin.com/ml/cygwin-xfree/2005-09/msg00028.html The system menu can be modified by the use of an .XWinrc file. In Joe's winmultiwindowwindow.c file patch SetupSysMenu is called directly instead of via the main WNDPROC with PostMessage (WM_INIT_SYS_MENU) to winmultiwindowwndproc.c. Reverting to the PostMessage/WM_INIT_SYS_MENU code, in both files, enables the 'Always on Top' system menu addition, for example, to work as intended. Thanks Colin Harrison -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Icon update .diff
Joe Krahn jkrahn-at-nc.rr.com |Lists| wrote: 3) Decide if Win95/Me/NT/2000 need continued support. Win 2000 - yes please... Peter -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Icon update .diff
Hi, Joe Krahn wrote: 3) Decide if Win95/Me/NT/2000 need continued support. Cygwin has dropped Me, Microsoft 95/98 (support 'till Jun 2006) and NT (dead now even if you pay). Typical Microsoft, though...you have to read loads of pages of guff until you can guess at the true story! Anyone tried Xwin/Xming on Vista? And then there is the possibility that loads of people may abandon Microsoft desktops when/if Apple move to Intel processors on cheap machines, or Gnome and/or KDE become de rigueur (pigs may fly). I vote for coding/maintenance for 2000/2003/XP and Vista for the time being, and can only test on 2003/XP. Colin Harrison -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Icon update .diff
On Sun, 4 Sep 2005, Joe Krahn wrote: When I use the CVS defaults, only multi-window mode is built, so I didn't see the #ifdef XWIN_MULTIWINDOW code compiled. Why is only one version built? Is it rootless mode that gets excluded? XWin has basicly 3 operation modes. windowed (includes -rootless and -fullscreen) -multiwindow -externalwm and -internalwm With rootless there is a name clash between the option -rootless (which does hide the root window only) and the XServer rootless extension. The rootless extension assigns every window its own small framebuffer rather than a global one which occupies the whole screen. so the XWIN_MULTIWINDOW refers to code specific to -multiwindow. XWIN_MULTIWINDOWEXTWM refers to the externalwm and internalwm code and the rootless extension. The rootless code is still not ready since it does crash easily because of memory access faults so it's not enable by default. Removing multiwindow support has also been handy when I ported to mingw and had no threads support. Disabling multiwindow and clipboard support also removed the pthread dependency. bye ago BTW: We always tried to maintain support for all windows systems until Win95 by providing alternative code paths if available. The GetProcAddress feature does help a lot. You should check out the code for EnumDisplayMonitors how this can be achieved. -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Icon update .diff
Hi, Another decision is what executables and dlls are built in distributions? Do we provide:- 1) Support for GL and Mesa only by two builds (current situation), where GL version is faster but less universally applicable? 2) Support for builds of both Xwin and Xming from the same source tree? 3) Additional specialist builds...I do my own xc/config/cf file changes, for instance, to optimise for Pentium processors and performance/codesize (~40% improvements easily made)? In the long run xorg is becoming modular (moving away from the original monolithic structure, we build against), should this be taken on board sooner or later? Colin Harrison -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Icon update .diff
On Mon, 5 Sep 2005, Colin Harrison wrote: Hi, Another decision is what executables and dlls are built in distributions? Do we provide:- About the current status: 1) Support for GL and Mesa only by two builds (current situation), where GL version is faster but less universally applicable? There is ongoing work to add a layer between xserver glx code and the OpenGL library (native or mesa) which will make it possibe to switch at runtime. The current code requires this decision at build/link time 2) Support for builds of both Xwin and Xming from the same source tree? It is already possible. The CYGWIN branch on freedesktop is only used for creating stable releases while the HEAD branch includes newer features like the internalwm code and some changes to the multiwindow code but were still evolving. Xming is built from HEAD because it required some changes to the code which I did not wanted to backport to the CYGWIN branch. 3) Additional specialist builds...I do my own xc/config/cf file changes, for instance, to optimise for Pentium processors and performance/codesize (~40% improvements easily made)? In the long run xorg is becoming modular (moving away from the original monolithic structure, we build against), should this be taken on board sooner or later? Some work is already done for building XWin from the modular tree but it is not working as expected. There will be a 6.9 _and_ 7.0 release the next months where the feature set and code is identical but the build system is different. With the current status only the 6.9 release will work for Cygwin but the monolithic tree will get abandoned in the next releases so following the modular path is a strict requirement. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Icon update .diff
On Mon, Sep 05, 2005 at 07:59:19AM +0100, Colin Harrison wrote: Joe Krahn wrote: 3) Decide if Win95/Me/NT/2000 need continued support. Cygwin has dropped Me, Microsoft 95/98 (support 'till Jun 2006) and NT (dead now even if you pay). I think you mean Microsoft has dropped the above. Cygwin still supports them. We don't mirror Microsoft wrt what we support. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Icon update .diff
Colin Harrison wrote: Hi, Another decision is what executables and dlls are built in distributions? Do we provide:- 1) Support for GL and Mesa only by two builds (current situation), where GL version is faster but less universally applicable? There should be one build with both renderers, handled just like Indirect/Mesa versus DRI in other X servers. 2) Support for builds of both Xwin and Xming from the same source tree? That will need separate versions of every object file, right? That is hard to do with the current design, but I have set up some Makefiles to prefix binary output files for multiple builds. I think this set up should really be more common, so one can build a Debug or Release versions without starting from scratch. 3) Additional specialist builds...I do my own xc/config/cf file changes, for instance, to optimise for Pentium processors and performance/codesize (~40% improvements easily made)? I think these types of tweaks are supposed to be confined to site.def if the main .cf is done right, but it seems that nobody distributes multiple example site.defs. This probably fits into the multiple-build Makefile idea. In the long run xorg is becoming modular (moving away from the original monolithic structure, we build against), should this be taken on board sooner or later? I would say later. As long as things get tweaked, Cygwin is likely to get a lot of incompatible changes. Best to wait until it is very stable. But, meanwhile, code additions and clean-ups should keep modularization in mind. Joe -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Icon update .diff
Peter Valdemar Morch wrote: Joe Krahn jkrahn-at-nc.rr.com |Lists| wrote: 3) Decide if Win95/Me/NT/2000 need continued support. Win 2000 - yes please... OK, I was thinking this might be the one case where it may be needed for a while. Can you build and/or test code changes? Thanks, Joe -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Icon update .diff
Hi,
All your diffs seem to work almost correctly (see below), but still testing.
In windialogs.c:-
Should SM_CXICONSM be SM_CXSMICON, SM_CYICONSM be SM_CYSMICON ?
Also had to remove the conditional on XWIN_MULTIWINDOW to get X icons
i.e.
--- my_windialogs.c 2005-09-03 22:36:08.0 +0100
+++ windialogs.c2005-09-04 11:44:22.0 +0100
@@ -213,18 +213,13 @@
0, 0,
SWP_NOSIZE);
-#if defined(XWIN_MULTIWINDOW)
- hIcon = g_hIconX;
- hIconSmall = g_hSmallIconX;
-#else
- hIcon = LoadIcon (g_hInstance, MAKEINTRESOURCE(IDI_XWIN)));
+ hIcon = LoadIcon (g_hInstance, MAKEINTRESOURCE(IDI_XWIN));
hIconSmall = LoadImage (g_hInstance,
MAKEINTRESOURCE(IDI_XWIN), IMAGE_ICON,
- GetSystemMetrics(SM_CXICONSM),
- GetSystemMetrics(SM_CYICONSM),
- LR_SHARED));
-#endif
+ GetSystemMetrics(SM_CXSMICON),
+ GetSystemMetrics(SM_CYSMICON),
+ LR_SHARED);
PostMessage (hwndDlg, WM_SETICON, ICON_BIG, (LPARAM) hIcon);
PostMessage (hwndDlg, WM_SETICON, ICON_SMALL, (LPARAM) hIconSmall);
In winmultiwindowwindow.c:-
Get some unused variables warnings, I just removed them:-
--- my_winmultiwindowwindow.c 2005-09-04 11:13:28.0 +0100
+++ winmultiwindowwindow.c 2005-09-04 11:14:32.0 +0100
@@ -520,10 +520,6 @@
winWindowPriv(pWin);
HICONhIcon;
HICONhIconSmall;
-#define CLASS_NAME_LENGTH 512
- char pszClass[CLASS_NAME_LENGTH], pszWindowID[12];
- char *res_name, *res_class, *res_role;
- static int s_iWindowID = 0;
winPrivScreenPtr pScreenPriv = pWinPriv-pScreenPriv;
WinXSizeHints hints;
@@ -610,11 +606,6 @@
{
MSG msg;
winWindowPriv(pWin);
- HICONhiconClass;
- HICONhiconSmClass;
- HMODULE hInstance;
- int iReturn;
- char pszClass[512];
BOOL oldstate = winInDestroyWindowsWindow;
#if CYGMULTIWINDOW_DEBUG
In winmultiwindowicons.c
(LPARAM) cast missing in
hIconOld = (HICON) SendMessage (pWinPriv-hWnd,
WM_SETICON, ICON_SMALL, hIconSmall);
We probably need to work through bugzilla to get these changes into the xorg
tree?
Thanks
Colin Harrison
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: Icon update .diff
Colin Harrison wrote: Hi, All your diffs seem to work almost correctly (see below), but still testing. In windialogs.c:- Should SM_CXICONSM be SM_CXSMICON, SM_CYICONSM be SM_CYSMICON ? Also had to remove the conditional on XWIN_MULTIWINDOW to get X icons It looks like that part of the code was #ifdef'ed out for XWIN_MULTIWINDOW. The intent was to use the two global overridable X icons for multiwindow mode, and get icons from the resources for other build modes. Maybe the multi-window mode needs to revert to resource icons if the global icons being undefined. I had set an override icon. As for Bugzilla, I would like to get a few more icon features tested, but maybe it's best to get bug-fixes sent in before trying enhancements. When I use the CVS defaults, only multi-window mode is built, so I didn't see the #ifdef XWIN_MULTIWINDOW code compiled. Why is only one version built? Is it rootless mode that gets excluded? Joe -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Icon update .diff
Joe Krahn wrote: When I use the CVS defaults, only multi-window mode is built, so I didn't see the #ifdef XWIN_MULTIWINDOW code compiled. Why is only one version built? Is it rootless mode that gets excluded? Mystery to me..the code is loaded with many ifdef's, the use of which is probably 'just-in-case' legacy stuff. Loosing a few as things are changed is maybe a good idea now. I only use GLX built versions and:- start Xwin :%DISNO% -emulate3buttons -multiwindow -clipboard -silent-dup-error -clipupdates 5 -fp tcp/%XFT%:7100 -xkbmodel pc105 -xkblayout g or start Xwin :%DISNO% -notrayicon -lesspointer -screen 0 1024x768+125+100 -query %XFT% -emulate3buttons -fp tcp/%XFT%:7100 -xkbmodel pc105 -xkblayout gb where XFT is a linux font server and DISTNO is the display 0,1,3 etc So my coding and testing tends not to stray beyond these uses, locales or into 'unix' window managers. All my X windows are also from remote linux clients (typically without graphics cards). Using bugzilla may mop up a few people with broader needs. I've also noticed that recent xorg tree changes blow us out of the water..I just had a problem with Xming loosing xkb stuff for instance, so Xwin changes can be driven from 'outside' this list's scope, even if we change nothing! Colin Harrison -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Icon update .diff
Colin Harrison wrote: Joe Krahn wrote: When I use the CVS defaults, only multi-window mode is built, so I didn't see the #ifdef XWIN_MULTIWINDOW code compiled. Why is only one version built? Is it rootless mode that gets excluded? Mystery to me..the code is loaded with many ifdef's, the use of which is probably 'just-in-case' legacy stuff. Loosing a few as things are changed is maybe a good idea now. I was wondering about things like global icons (g_hIcon) which are #ifdef'ed in shared code to be used with XWIN_MULTIWINDOW, yet only the multiwindow code sets these icons. I guess there's a need for a round of overall code clean up. But, it works right now, so the incentive is small. It seems to me that it needs: 1) A review of globals, with true globals being made uniform across the root-window[less] modes, and other not-so-globals made non-global. 2) Get rid of unused 'legacy' #ifdef code. 3) Decide if Win95/Me/NT/2000 need continued support. 4) Reorganize files: get rid of the common win- prefix, and replace mode-specific prefixes with a directory, so xwin/winmultiwindowicons.c becomes xwin/multiwindow/icons.c. I think these could be done successfully without too much effort. But, these need some maintainer decisions first. Joe -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
