From: <pe...@ce...> - 2002-11-20 16:06:42
|
I've released a new version of rdesktop, 1.2beta1. This is a beta version= =20 of the upcoming 1.2 release.=20 If you find bugs, please submit these to the Sourceforge Bug Tracker=20 (http://sourceforge.net/tracker/?group_id=3D24366&atid=3D381347).=20 Note that this is a development release, with known bugs. For example, th= e=20 keyboard translation maps are incomplete.=20 For patches, corrections or general discussions, use the rdesktop mailing= =20 lists (http://sourceforge.net/mail/?group_id=3D24366).=20 /Peter =C5strand, rdesktop team |
From: Christopher O. <ode...@hn...> - 2002-11-21 09:41:15
|
Hi, > I've released a new version of rdesktop, 1.2beta1. This is a beta > version of the upcoming 1.2 release. > > If you find bugs, please submit these to the Sourceforge Bug Tracker > (http://sourceforge.net/tracker/?group_id=24366&atid=381347). I am missing the -v switch for private colormaps. You cannot work properly on Sun Ultra 1 systems without. There is another system independant drawing bug (occurs on linux and on solaris) which can be reproduced as follows: - Start Excel - Fill up a few fields with data - Mark a few fields and press ctrl-c (copy) - Put the cursor on another field and press ctrl-v (paste) - Put the cursor elsewhere, paste again At every paste a rectangular frame is left on the screen. They disappear when excel is minimized and maximized again, so it's a bug, not a feature. This bug has been in rdesktop since I know it exists, so for quite a while... I have added this bug to the SF bug tracker. Christopher |
From: <pe...@ce...> - 2002-11-21 09:53:53
|
> > I've released a new version of rdesktop, 1.2beta1. This is a beta > > version of the upcoming 1.2 release. > I am missing the -v switch for private colormaps. You cannot work=20 > properly on Sun Ultra 1 systems without. What is the reason for this? Is Ultra1 using some strange visuals?=20 There must be some way to detect this automatically. I assume you don't=20 need to specify -v flags for all other applications like Mozilla, Acrobat= =20 Reader etc, right? > - Start Excel > - Fill up a few fields with data > - Mark a few fields and press ctrl-c (copy) > - Put the cursor on another field and press ctrl-v (paste) > - Put the cursor elsewhere, paste again >=20 > At every paste a rectangular frame is left on the screen. They=20 > disappear when excel is minimized and maximized again, so it's a bug,=20 > not a feature. >=20 > This bug has been in rdesktop since I know it exists, so for quite a=20 > while... Yes, I've seen it myself.=20 > I have added this bug to the SF bug tracker. Thanks! --=20 Peter =C5strand Telephone: +46-13-21 46 00 Cendio Systems E-mail: pe...@ce... Teknikringen 3 583 30 Link=F6ping |
From: Christopher O. <ode...@hn...> - 2002-11-21 10:30:01
|
Hi, > > I am missing the -v switch for private colormaps. You cannot work > > properly on Sun Ultra 1 systems without. > > What is the reason for this? Is Ultra1 using some strange visuals? These boxes can only cope with 256 colors. CDE is quite greedy concerning colors, so there is not much left for rdesktop. Until last week rdesktop-1.1.0-pl19-9-0 ran quite well. Then we installed an Xsun patch which had quite an ugly side effect: rdesktop does not show the windows cursor anymore (in the login screen or in "Start/Run..."). Switching to a private color map does the trick. > There must be some way to detect this automatically. I assume you > don't need to specify -v flags for all other applications like > Mozilla, Acrobat Reader etc, right? Depends on what you are looking at. For convenient surfing it really is better to give netscape its own color map (true color images look sort of ugly when viewed with < 200 colors). It depends on your desktop. If you have a lot of nice colored icons on your screen you have a good chance of looking at crappy websites without a private colormap. > > At every paste a rectangular frame is left on the screen. They > > disappear when excel is minimized and maximized again, so it's a > > bug, not a feature. > > > > This bug has been in rdesktop since I know it exists, so for quite > > a while... > > Yes, I've seen it myself. Good. Any chance of getting it out? Have you any idea where the bug could lie? > > I have added this bug to the SF bug tracker. > > Thanks! No problem. Thanks to you for a really good work! Besides these small remarks the new beta looks very good! Christopher -- ====================================================== Dipl.-Ing. Christopher Odenbach HNI Rechnerbetrieb ode...@un... Tel.: +49 5251 60 6215 ====================================================== |
From: <pe...@ce...> - 2002-11-21 10:43:17
|
> > > I am missing the -v switch for private colormaps. You cannot work > > > properly on Sun Ultra 1 systems without. > > > > What is the reason for this? Is Ultra1 using some strange visuals? >=20 > These boxes can only cope with 256 colors. CDE is quite greedy=20 > concerning colors, so there is not much left for rdesktop. patches.txt says: " http://bibl4.oru.se/projects/rdesktop/patch19/patches/backingstore+privat= ecolormap-for-19-3-9.patch Description: This adds support for 1) Private color maps (useful for 8 bpp mode) and 2) backingstore selection.=20 Status: 1) is not needed anymore; rdesktop automatically uses Private color map in 8 bpp mode. 2) is, as far as I understand, also not need. rdesktop automatically uses a software backing store if the Xserver does not provide one.=20 " So, according to this file, rdesktop should automatically use a private color map. But when I take a quick look at the code, I cannot find this=20 code. Maybe patches.txt is wrong? (Yes I know I've written it :-) > > > This bug has been in rdesktop since I know it exists, so for quite > > > a while... > > > > Yes, I've seen it myself. >=20 > Good. Any chance of getting it out? Have you any idea where the bug=20 > could lie? Personally, I have no idea.=20 > No problem. Thanks to you for a really good work! Besides these small=20 > remarks the new beta looks very good! Good.=20 --=20 Peter =C5strand Telephone: +46-13-21 46 00 Cendio Systems E-mail: pe...@ce... Teknikringen 3 583 30 Link=F6ping |
From: Christopher O. <ode...@hn...> - 2002-11-21 10:58:50
|
Hi, > > These boxes can only cope with 256 colors. CDE is quite greedy > > concerning colors, so there is not much left for rdesktop. > > patches.txt says: > > " > http://bibl4.oru.se/projects/rdesktop/patch19/patches/backingstore+pr >ivatecolormap-for-19-3-9.patch Description: > This adds support for 1) Private color maps (useful for 8 bpp mode) > and 2) backingstore selection. > Status: > 1) is not needed anymore; rdesktop automatically uses Private color > map in 8 bpp mode. 2) is, as far as I understand, also not > need. rdesktop automatically uses a software backing store if the > Xserver does not provide one. > " > > So, according to this file, rdesktop should automatically use a > private color map. But when I take a quick look at the code, I cannot > find this code. Maybe patches.txt is wrong? (Yes I know I've written > it :-) 1.2beta1 definitly does not switch automagically. Tell me if I can assist you - and how. Regards, Christopher |
From: <pe...@ce...> - 2002-11-21 12:17:47
|
On Thu, 21 Nov 2002, Christopher Odenbach wrote: > > So, according to this file, rdesktop should automatically use a > > private color map. But when I take a quick look at the code, I cannot > > find this code. Maybe patches.txt is wrong? (Yes I know I've written > > it :-) >=20 > 1.2beta1 definitly does not switch automagically. >=20 > Tell me if I can assist you - and how. I suppose we need to integrate the colormap part of http://bibl4.oru.se/projects/rdesktop/patch19/patches/backingstore+privat= ecolormap-for-19-3-9.patch,=20 but make rdesktop automatically use a private colormap when bpp =3D 8,=20 instead of using the -v option.=20 --=20 Peter =C5strand Telephone: +46-13-21 46 00 Cendio Systems E-mail: pe...@ce... Teknikringen 3 583 30 Link=F6ping |
From: Matt C. <mat...@cs...> - 2002-11-21 12:24:51
|
On Thu, Nov 21, 2002 at 01:17:28PM +0100, Peter ?strand wrote: > On Thu, 21 Nov 2002, Christopher Odenbach wrote: > > > > So, according to this file, rdesktop should automatically use a > > > private color map. But when I take a quick look at the code, I cannot > > > find this code. Maybe patches.txt is wrong? (Yes I know I've written > > > it :-) > > > > 1.2beta1 definitly does not switch automagically. > > > > Tell me if I can assist you - and how. > > I suppose we need to integrate the colormap part of > http://bibl4.oru.se/projects/rdesktop/patch19/patches/backingstore+privatecolormap-for-19-3-9.patch, > but make rdesktop automatically use a private colormap when bpp = 8, > instead of using the -v option. This was what I did before, the private colourmap code was removed by other-Peter in revision 1.60 of xwin.c. I think it's probably worth reinstating it. Matt -- Revision 1.60 / (view) - annotate - [select for diffs] , Wed Sep 18 12:13:08 2002 UTC (2 months ago) by n-ki Branch: MAIN Changes since 1.59: +61 -58 lines Diff to previous 1.59 Owncolmap removed in favour of more intelligent color allocation. |
From: Peter <pet...@ub...> - 2002-11-22 08:39:39
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > > > So, according to this file, rdesktop should automatically use a > > > > private color map. But when I take a quick look at the code, I ca= nnot > > > > find this code. Maybe patches.txt is wrong? (Yes I know I've writ= ten > > > > it :-) > > > > > > 1.2beta1 definitly does not switch automagically. > > > > > > Tell me if I can assist you - and how. > > > > I suppose we need to integrate the colormap part of > > http://bibl4.oru.se/projects/rdesktop/patch19/patches/backingstore+pr= ivat > >ecolormap-for-19-3-9.patch, but make rdesktop automatically use a priv= ate > > colormap when bpp =3D 8, instead of using the -v option. > > This was what I did before, the private colourmap code was removed by > other-Peter in revision 1.60 of xwin.c. =20 yes I removed it... :\ > I think it's probably worth reinstating it. it seems so, however it was producing worce colormatches than the code we= use=20 now, atleast on the 8-bit screens we have here, and a few others that I k= now=20 of. Perhaps we should have both, i.e. the private colormap switch to be a= =20 manual option for the environments that need it, and the current code-pat= h to=20 be the default? regards, peter > > Matt > > > -- > > Revision 1.60 / (view) - annotate - [select for diffs] , Wed Sep 18 > 12:13:08 2002 UTC (2 months ago) by n-ki Branch: MAIN > Changes since 1.59: +61 -58 lines > Diff to previous 1.59 > > Owncolmap removed in favour of more intelligent color allocation. > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > rdesktop-devel mailing list > rde...@li... > https://lists.sourceforge.net/lists/listinfo/rdesktop-devel - --=20 Peter Bystr=F6m <pet...@ub...> Systemstechnician =D6rebro UNI, Library =20 PGP Key-ID: 0x41C60D62 - -- Some Windows were made to be broken. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE93e0dqORp8UHGDWIRAgzHAKCLQxngrsUwSjCwaQukUdedwoH/7QCeMdrx meF0zOD5OTAx86bY9WfWJ8I=3D =3DV4QC -----END PGP SIGNATURE----- |
From: Christopher O. <ode...@hn...> - 2002-11-22 09:52:01
|
Hi, > > > I suppose we need to integrate the colormap part of > > > http://bibl4.oru.se/projects/rdesktop/patch19/patches/backingstor > > >e+privat ecolormap-for-19-3-9.patch, but make rdesktop > > > automatically use a private colormap when bpp = 8, instead of > > > using the -v option. > > > > This was what I did before, the private colourmap code was removed > > by other-Peter in revision 1.60 of xwin.c. > > yes I removed it... :\ > > > I think it's probably worth reinstating it. > > it seems so, however it was producing worce colormatches than the > code we use now, atleast on the 8-bit screens we have here, and a few > others that I know of. Perhaps we should have both, i.e. the private > colormap switch to be a manual option for the environments that need > it, and the current code-path to be the default? Sounds good. One switch to force a private colormap, one to force the global colormap, default to auto. This should cover all cases users can think of. :-) Christopher |