Re: Design decisions for GLib and GTK+ on Win32
Tor Lillqvist wrote: - Can the support for 256-colour (palettized) display mode be dropped from GTK+ HEAD? I'm not doing this, not yet at least. If I can figure out a way to test whether 256-colour mode works currently, and it doesn't, I will drop it though... 256 color compatibility is the only thing from the original list that I think maybe should be retained because of remote desktop performance. You can test by running through terminal services, aka remote desktop. The number of colors can be set in the client before connecting. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Design decisions for GLib and GTK+ on Win32
On Tue, 29 Aug 2006 10:24:05 +0300, Tor Lillqvist wrote: (It's for 256-colour mode that I don't seem to even have anything to test with. Not even in a virtual machine (running XP) does Display Settings offer a 256-colour mode. Is it really so that modern Windows graphics card drivers only support truecolor, except perhaps in full-screen modes for old games?) My machine at work (XP pro) allows me to set 8bit mode (it has Intel on-board graphics, SiS 315 and some old Matrox PCI cards). -- Jernej Simončič http://deepthought.ena.si/ Contact address: jernej simoncic at isg si ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gtk-devel-list] Design decisions for GLib and GTK+ on Win32
[EMAIL PROTECTED] writes: Is it possible to configure the text layout engine for each script, when Uniscribe is used by default? If there existed other layout engines for the win32 pango backend, yes. But there is only basic-win32, which uses Uniscribe. (Note that this doesn't have anything to do with the Subject any longer.) --tml ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gtk-devel-list] Design decisions for GLib and GTK+ on Win32
C.J. Adams-Collier writes: Feel free to vote for or against deprecating gtk+ support for win95, win98 and winME here: We are talking about HEAD, which is known not to work on win9x anyway, so deprecating support is an exaggeration. But what I propose is that the remains of win9x-specific code should be taken out (from HEAD), and that win2k-and-newer-only APIs can freely be used from now on. If somebody eventually creeps out of the woodwork and volunteers to make it work on win9x, I would strongly suggest they used a MSLU-based approach instead of (re)introducing win9x code and runtime optionality of win2k-only APIs. (MSLU = Microsoft Layer for Unicode, see MSDN.) --tml ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gtk-devel-list] Design decisions for GLib and GTK+ on Win32
I'm sorry for keeping discussion without win9x volunteer. On Tue, 29 Aug 2006 11:23:35 +0300 Tor Lillqvist [EMAIL PROTECTED] wrote: If somebody eventually creeps out of the woodwork and volunteers to make it work on win9x, I would strongly suggest they used a MSLU-based approach instead of (re)introducing win9x code and runtime optionality of win2k-only APIs. (MSLU = Microsoft Layer for Unicode, see MSDN.) Thank you for info. How about multithreading and memory management APIs? Win2k-and-newer APIs are already introduced for such? Regards, mpsuzuki ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gtk-devel-list] Design decisions for GLib and GTK+ on Win32
[EMAIL PROTECTED] writes: How about multithreading and memory management APIs? Win2k-and-newer APIs are already introduced for such? No, those parts of GLib use functions that are present on all Windows platforms. --tml ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gtk-devel-list] Design decisions for GLib and GTK+ on Win32
On Tue, 29 Aug 2006 11:45:11 +0300 Tor Lillqvist [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: How about multithreading and memory management APIs? Win2k-and-newer APIs are already introduced for such? No, those parts of GLib use functions that are present on all Windows platforms. Good, now I have no reason to object against the removal of current win9x-specific code, because better implementation by MSLU is suggested. (and I think it's right solution.) Regards, mpsuzuki ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Design decisions for GLib and GTK+ on Win32
I wrote: - Can the support for Win9x be dropped from GLib and GTK+ HEAD? Note that cairo has never worked on Win9x, so GTK+ has de facto not worked on Win9x since 2.8 anyway. OK, there seemes to be no major opposition to this, being done now. - Can the support for 256-colour (palettized) display mode be dropped from GTK+ HEAD? I'm not doing this, not yet at least. If I can figure out a way to test whether 256-colour mode works currently, and it doesn't, I will drop it though... - Can support for the ActiveIMM thingie used to implement IMEs on NT4 (and Win9x) be dropped? I am doing this, too. - Can Uniscribe be made non-optional in pangowin32? I am not sure about this yet. It should be self-evident that a production build of Pango should use Uniscribe. But maybe it is a good idea to continue letting people who want to debug or developer Pango on Win32, and can't be bothered to download the Platform SDK, build it without Uniscribe, though. --tml ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gtk-devel-list] Design decisions for GLib and GTK+ on Win32
On Mon, 28 Aug 2006, C.J. Adams-Collier wrote: Feel free to vote for or against deprecating gtk+ support for win95, win98 and winME here... It's much too late to vote with regard to win95, IMO. Gtk has been broken on that platform for ages, and I hardly think anyone is going to invest time fixing gtk on a crap OS that's over 10 years past its sell-by date. Win98 is a somewhat different issue, since that OS is not totally broken and is still quite prevalent in some quarters. But here I take Tor's point: if you want to support win98 (as I do, in fact, for my gtk app), use the gtk 2.6 runtime. Allin Cottrell Wake Forest University ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gtk-devel-list] Design decisions for GLib and GTK+ on Win32
Hi, On Fri, 25 Aug 2006 22:33:13 +0300 Tor Lillqvist [EMAIL PROTECTED] wrote: - Can the support for Win9x be dropped from GLib and GTK+ HEAD? Note that cairo has never worked on Win9x, so GTK+ has de facto not worked on Win9x since 2.8 anyway. Dropping Win9x support would mean (slightly) cleaner source code in a couple of files. I vote No, but please let me ask a silly question: if cairo works on Win9x, GTK+ HEAD will work as newer Win32 platforms? Or, even if cairo works on Win9x, more additional (and hard to maintain) codes for Win95 are required? - Can the support for 256-colour (palettized) display mode be dropped from GTK+ HEAD? I have no idea whether it even works currently, and I can't test as my display adapter doesn't even offer a 256-colour mode in Display Properties. If it doesn't work, which I suspect, who is going to fix it? Not I anyway... The support for palettized displays is very ugly and ad-hoc code, it would be a relief to get rid of it. I have no idea. - Can support for the ActiveIMM thingie used to implement IMEs on NT4 (and Win9x) be dropped? Again, I have no idea whether it currently works anyway... (On Windows 2000 and later IMEs are built in, no separate thingie is needed.) Either I don't know whether it is still working, but I vote No. - Can Uniscribe be made non-optional in pangowin32? This would just mean dropping some lines of configure.in, and dropping some ifdefs from basic-win32.c. Having it even possible to build pangowin32 without Uniscribe kinda defeats the whole purpose of Pango, doesn't it? As I vote Not to the first question, I should vote No again. BTW, the request of Uniscribe backend is for Unicode text layout by Uniscribe instead of HarfBuzz? Anything else? Regards, mpsuzuki ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gtk-devel-list] Design decisions for GLib and GTK+ on Win32
Hi, Before all, I have to apologize that I vote No in spite of I'm not GTK+/Win95 developer. On Mon, 28 Aug 2006 11:33:21 +0300 Tor Lillqvist [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: I vote No, but please let me ask a silly question: if cairo works on Win9x, GTK+ HEAD will work as newer Win32 platforms? I have no idea. GTK+ 2.8 might. But is there somebody working on making cairo run on Win9x? I remember, a guy was trying to port cairo to Win9x, although yet I've not heard successful report, at present. And if somebody did this, wouldn't it be enough to keep the Win9x support in GTK+ 2.10 (and earlier), and retire it from HEAD? Dropping Win9x code from HEAD means GTK+ 2.12 won't support for Win9x? Excuse me, I don't understand what you mean enough. Or, even if cairo works on Win9x, more additional (and hard to maintain) codes for Win95 are required? Well, I wouldn't call the code hard to maintain as such, just messy. But it's not just a question of having to keep two code paths (one using wide characters strigns and W APIs, the other using system codepage char strings and A APIs) here and there. Some APIs that would be useful to use aren't available at all on Win9x, like GetFontUnicodeRanges. (Although GetFontUnicodeRanges seems to be broken in the sense that it can't handle fonts with coverage outside the BMP, so we couldn't use it anyhow, sigh.) I see. Do you think it is possible that packaging Win95 support code as separate library? BTW, the request of Uniscribe backend is for Unicode text layout by Uniscribe instead of HarfBuzz? Anything else? Er, Harfbuzz doesn't do the same thing Uniscribe, does it? Uniscribe is what takes care of the complex script processing, for which on Unix Pango uses the code in the pango-arabic-fc, pango-hangul-fc, pango-hebrew-fc, pango-indic-fc etc modules. Or am I confused? Ah, sorry, I was confused and my English is too poor. Let me explain wordily. I guess, the import Uniscribe into pangowin32 is requested to add complex script rendering feature to pangowin32 itself. By Uniscribe rendering, the complex script rendering would be exactly same with popular Win32 applications (e.g. wordpad.exe). I guess it is the advantage prioritized by the people who request default-and-builtin Uniscribe support. Am I right? Regards, mpsuzuki ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gtk-devel-list] Design decisions for GLib and GTK+ on Win32
[EMAIL PROTECTED] writes: I remember, a guy was trying to port cairo to Win9x, although yet I've not heard successful report, at present. OK. Doesn't sound too promising, then. Dropping Win9x code from HEAD means GTK+ 2.12 won't support for Win9x? Yes. For GTK+ 2.10 the situation is the same as for 2.8, i.e. it would presumably work otherwise, if cairo would. I see. Do you think it is possible that packaging Win95 support code as separate library? Yes. The separate library is calld GTK+ 2.6 ;) I guess, the import Uniscribe into pangowin32 is requested to add complex script rendering feature to pangowin32 itself. By Uniscribe rendering, the complex script rendering would be exactly same with popular Win32 applications (e.g. wordpad.exe). Yes. (would is wrong, it *is* (one would hope) and has been for a long time.) I guess it is the advantage prioritized by the people who request default-and-builtin Uniscribe support. Am I right? Hmm, I don't really understand what you mean here. There are no alternatives to Uniscribe for Pango on Win32. There is code in Pango itself for complex script processing only when using the fontconfig-based backends. The Uniscribe use in Pango is currently optional both during configuration/compilation, and during runtime. I am suggesting that the optionality during configuration/compilation could be removed. (Thus one would have to have the Platform SDK, or at least just usp10.h, on the machine where one builds Pango.) The code would still check at run-time for the availability of usp10.dll, and link to it dynamically. Thus one might still be able to use pangowin32 on Win9x... but that is mostly a pointless fact as GTK+ uses pangocairo (which uses cairo and pangowin32). --tml ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gtk-devel-list] Design decisions for GLib and GTK+ on Win32
On Mon, 2006-08-28 at 04:33 -0400, Tor Lillqvist wrote: Er, Harfbuzz doesn't do the same thing Uniscribe, does it? No. HarfBuzz is basically the equivalent of the OTLS library on Win32 systems: http://www.microsoft.com/typography/developers/otls/default.htm -- behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gtk-devel-list] Design decisions for GLib and GTK+ on Win32
On Mon, 28 Aug 2006 14:39:11 +0300 Tor Lillqvist [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: Dropping Win9x code from HEAD means GTK+ 2.12 won't support for Win9x? Yes. For GTK+ 2.10 the situation is the same as for 2.8, i.e. it would presumably work otherwise, if cairo would. I see. I see. Do you think it is possible that packaging Win95 support code as separate library? Yes. The separate library is calld GTK+ 2.6 ;) Umm, what I mean was something like an optional win95 support library for GTK+ HEAD, not forked version of GTK+/Win9x. Anyway, due to the fact that GTK+ has been unworking on Win9x for a long time, I must change my thought. I ask, removing of Win9x related codes should be done at one time, and should not be mixed with other update. It makes easy that somebody retrieve the removed Win9x related code by simple CVS diff. I guess, the import Uniscribe into pangowin32 is requested to add complex script rendering feature to pangowin32 itself. By Uniscribe rendering, the complex script rendering would be exactly same with popular Win32 applications (e.g. wordpad.exe). Yes. (would is wrong, it *is* (one would hope) and has been for a long time.) I see. I guess it is the advantage prioritized by the people who request default-and-builtin Uniscribe support. Am I right? Hmm, I don't really understand what you mean here. There are no alternatives to Uniscribe for Pango on Win32. There is code in Pango itself for complex script processing only when using the fontconfig-based backends. Ah, what I meant was almost same with previous line, you already answered enoughly, sorry. The code would still check at run-time for the availability of usp10.dll, and link to it dynamically. Thus one might still be able to use pangowin32 on Win9x... but that is mostly a pointless fact as GTK+ uses pangocairo (which uses cairo and pangowin32). I was not aware of dynamic check of usp10.dll availability, sounds interesting. Could we restrict pango to use Uniscribe as simple left-to-right text rendering? If so, I change my vote to Yes. And, is it possible to switch complexed text layout system between Uniscribe and HarfBuzz dynamically? (dynamically means no application restart, no reconfiguration of /etc/pango/pango.modules) Regards, mpsuzuki ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gtk-devel-list] Design decisions for GLib and GTK+ on Win32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED], Good thoughts. As more folks make known their need for win95 or win98 support, more care will likely be taken to make such win9x backports (and future backports) easier. Feel free to vote for or against deprecating gtk+ support for win95, win98 and winME here: http://wiki.colliertech.org/index.php/Vote:Win9xDeprecation Cheers, C.J. [EMAIL PROTECTED] wrote: On Mon, 28 Aug 2006 14:39:11 +0300 Tor Lillqvist [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: Dropping Win9x code from HEAD means GTK+ 2.12 won't support for Win9x? Yes. For GTK+ 2.10 the situation is the same as for 2.8, i.e. it would presumably work otherwise, if cairo would. I see. I see. Do you think it is possible that packaging Win95 support code as separate library? Yes. The separate library is calld GTK+ 2.6 ;) Umm, what I mean was something like an optional win95 support library for GTK+ HEAD, not forked version of GTK+/Win9x. Anyway, due to the fact that GTK+ has been unworking on Win9x for a long time, I must change my thought. I ask, removing of Win9x related codes should be done at one time, and should not be mixed with other update. It makes easy that somebody retrieve the removed Win9x related code by simple CVS diff. I guess, the import Uniscribe into pangowin32 is requested to add complex script rendering feature to pangowin32 itself. By Uniscribe rendering, the complex script rendering would be exactly same with popular Win32 applications (e.g. wordpad.exe). Yes. (would is wrong, it *is* (one would hope) and has been for a long time.) I see. I guess it is the advantage prioritized by the people who request default-and-builtin Uniscribe support. Am I right? Hmm, I don't really understand what you mean here. There are no alternatives to Uniscribe for Pango on Win32. There is code in Pango itself for complex script processing only when using the fontconfig-based backends. Ah, what I meant was almost same with previous line, you already answered enoughly, sorry. The code would still check at run-time for the availability of usp10.dll, and link to it dynamically. Thus one might still be able to use pangowin32 on Win9x... but that is mostly a pointless fact as GTK+ uses pangocairo (which uses cairo and pangowin32). I was not aware of dynamic check of usp10.dll availability, sounds interesting. Could we restrict pango to use Uniscribe as simple left-to-right text rendering? If so, I change my vote to Yes. And, is it possible to switch complexed text layout system between Uniscribe and HarfBuzz dynamically? (dynamically means no application restart, no reconfiguration of /etc/pango/pango.modules) Regards, mpsuzuki ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE868EbS8rWWzCfqgRAl7jAJ4oi6r7uz2SSobmHBQXI1tVBAAnzQCgjZ/4 ratJ/wH2umv3YBZiq/osVeA= =4w+o -END PGP SIGNATURE- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gtk-devel-list] Design decisions for GLib and GTK+ on Win32
On 29/08/06, C.J. Adams-Collier [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED], Good thoughts. As more folks make known their need for win95 or win98 support, more care will likely be taken to make such win9x backports (and future backports) easier. Feel free to vote for or against deprecating gtk+ support for win95, win98 and winME here: http://wiki.colliertech.org/index.php/Vote:Win9xDeprecation Note that votes alone probably aren't enough to ensure continuing support. It will require developer time and testers to make sure it continues to work. From Tor's original email, it sounds like he doesn't currently have a system to test Win9x support with. Is anyone else offering to do this testing? If maintaining Win9x support turns out to be non-trivial (getting Cairo running properly may be, for instance), is anyone willing to help with the development. Given limited resources, developers will usually focus on the areas that will benefit most users. For Windows, this means making it work well on NT derivatives. For X systems, it means making it work well for systems with RENDER. James. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Design decisions for GLib and GTK+ on Win32
I think now is the time to decide a couple of issues: - Can the support for Win9x be dropped from GLib and GTK+ HEAD? Note that cairo has never worked on Win9x, so GTK+ has de facto not worked on Win9x since 2.8 anyway. Dropping Win9x support would mean (slightly) cleaner source code in a couple of files. - Can the support for 256-colour (palettized) display mode be dropped from GTK+ HEAD? I have no idea whether it even works currently, and I can't test as my display adapter doesn't even offer a 256-colour mode in Display Properties. If it doesn't work, which I suspect, who is going to fix it? Not I anyway... The support for palettized displays is very ugly and ad-hoc code, it would be a relief to get rid of it. - Can support for the ActiveIMM thingie used to implement IMEs on NT4 (and Win9x) be dropped? Again, I have no idea whether it currently works anyway... (On Windows 2000 and later IMEs are built in, no separate thingie is needed.) - Can Uniscribe be made non-optional in pangowin32? This would just mean dropping some lines of configure.in, and dropping some ifdefs from basic-win32.c. Having it even possible to build pangowin32 without Uniscribe kinda defeats the whole purpose of Pango, doesn't it? My vote is yes on all counts ;) --tml ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Design decisions for GLib and GTK+ on Win32
On 8/25/06, Tor Lillqvist [EMAIL PROTECTED] wrote: I think now is the time to decide a couple of issues: - Can the support for Win9x be dropped from GLib and GTK+ HEAD? Note that cairo has never worked on Win9x, so GTK+ has de facto not worked on Win9x since 2.8 anyway. Dropping Win9x support would mean (slightly) cleaner source code in a couple of files. - Can the support for 256-colour (palettized) display mode be dropped from GTK+ HEAD? I have no idea whether it even works currently, and I can't test as my display adapter doesn't even offer a 256-colour mode in Display Properties. If it doesn't work, which I suspect, who is going to fix it? Not I anyway... The support for palettized displays is very ugly and ad-hoc code, it would be a relief to get rid of it. - Can support for the ActiveIMM thingie used to implement IMEs on NT4 (and Win9x) be dropped? Again, I have no idea whether it currently works anyway... (On Windows 2000 and later IMEs are built in, no separate thingie is needed.) - Can Uniscribe be made non-optional in pangowin32? This would just mean dropping some lines of configure.in, and dropping some ifdefs from basic-win32.c. Having it even possible to build pangowin32 without Uniscribe kinda defeats the whole purpose of Pango, doesn't it? My vote is yes on all counts ;) I don't know much about win32 or GTK+ on that platform, but my uninformed vote is yes on all counts, too. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Design decisions for GLib and GTK+ on Win32
I don't know much about win32 or GTK+ on that platform, but my uninformed vote is yes on all counts, too. Thirded. -Dom -- Counting bodies like sheep to the rhythm of the war drums. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Design decisions for GLib and GTK+ on Win32
C.J. Adams-Collier writes: Do we have any means by which we can determine what our user base is for each platform? Yes. For GTK+ 2.8, which was the *previous* stable (in a source code maintenance -sense) series, the user percentage on Win9x is zero. (As I said, cairo doesn't work on Win9x, and nobody has bothered enough to fix that, i.e. submit patches.) Those who use GTK+ 2.6 on Win9x can continue to do so, without any chance of bug fixes (from me at least), like they have for a year (since 2.8.0 was released). You've got my vote on all counts, Tor. Let's clean up the codebase. Thanks ;) --tml ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Design decisions for GLib and GTK+ on Win32
On 2006-08-25 11:31:16 PM, Tor Lillqvist wrote: Those who use GTK+ 2.6 on Win9x can continue to do so, without any chance of bug fixes (from me at least), like they have for a year (since 2.8.0 was released). Quite so. I'm all for dropping this stuff from 2.12. Cheers, Ali. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
