Re: pine in other distributions?
Piotr Roszatycki wrote: > > On Tue, 28 Sep 1999, Johnie Ingram wrote: > > > David> Redistribution of binary versions is further constrained by > > David> license agreements for incorporated libraries from third > > David> parties, e.g. LDAP, GSSAPI. > > > > Although the above trademark and copyright restrictions do not > > convey the right to redistribute derivative works, the University > > of Washington encourages unrestricted distribution of patch files > > which can be applied to the University of Washington Pine > > distribution. > > > > Did something change? Have they seen the Light? > > Is it possible to redistribute modified binaries? "...do not convey the right to redistribute derivative works" -- any and all modifications result in a derivative work. You can make local versions, you just can't give them to anyone else unless it's in the form of a patch. -- | Jeff Teunissen -- President, Dusk To Dawn Computing -- [EMAIL PROTECTED] | Disclaimer: I am my employer, so anything I say goes for me too. :) | dusknet.ddns.org is a black hole for email.Use my Reply-To address. | Specializing in Debian GNU/Linux http://dusknet.dhis.org/~deek/
Re: ITR: intent to rename poc to objc
Raul Miller wrote: > > On Thu, Sep 30, 1999 at 09:05:43PM +0200, Marcel Harkema wrote: > > I am going to rename the poc (portable object compiler) package to > > objc if no-one objects. The upstream author requested this. Also, > > libgc4 (boehm gc) support is dropped. A new additional package will > > be introduced with libgc5 support. > > Does this mean that this compiler can deal with objective C? > > [Note: this isn't an objection, but if you do this and they're not the > same thing you'll need to deal with the confusion somehow.] The POC handles Objective-C by translating it to C++, IIRC. -- | Jeff Teunissen -- President, Dusk To Dawn Computing -- [EMAIL PROTECTED] | Disclaimer: I am my employer, so anything I say goes for me too. :) | dusknet.ddns.org is a black hole for email.Use my Reply-To address. | Specializing in Debian GNU/Linux http://dusknet.dhis.org/~deek/
Re: Qt2.2 released under the GPL
Bas Zoetekouw wrote: > > Thus spake happ ([EMAIL PROTECTED]): > > > enough said > > http://www.trolltech.com > > now we can move the ftp://kde.tdyc.com/pub/kde potato kde2 contrib > > back home > > Great! Has anyone yet packages available? If not, I'll be willing to ITP > some. Qt 2.2 hasn't been released yet. Supposed to be released soon (Thursday?) though. -- | Jeff Teunissen - Pres., Dusk To Dawn Computing - deek at dusknet.dhs.org | Disclaimer: I am my employer, so anything I say goes for me too. :) | Core developer, The QuakeForge Projecthttp://www.quakeforge.net/ | Specializing in Debian GNU/Linux http://dusknet.dhs.org/~deek/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian and KDE: Appology
Paul Seelig wrote: > > On Fri, Sep 08, 2000 at 11:29:37AM +0200, Paul Slootman wrote: > > On Fri 08 Sep 2000, Paul Seelig wrote: > > > > > RMS should IMHO publically apologize with the KDE people for this > > > condescending part of his otherwise correct article. He should be > > > > So now _you_ are telling someone to ask for forgiveness? > > > And *in this case* righfully so and without being derisive. What an > ironic turn, isn't it? RMS was offering forgiveness for any FSF code that was infringed upon -- meaning nobody had to ask him for /anything/ -- and suggesting that the KDE developers ask for the same forgiveness from the developers of the GPL code they used (ostensibly only in two optional components, kmidi and kghostview), and which they lost legal access to by being in violation of its license. Somewhere along the line, this quite reasonable, non-derisive suggestion was turned into "I demand you beg my personal forgiveness for violating the GPL, and by the way, GNOME is still going to bury you", which is completely derisive and completely unreasonable...and which never happened. -- | Jeff Teunissen - Pres., Dusk To Dawn Computing - deek at dusknet.dhs.org | Disclaimer: I am my employer, so anything I say goes for me too. :) | Core developer, The QuakeForge Projecthttp://www.quakeforge.net/ | Specializing in Debian GNU/Linux http://dusknet.dhs.org/~deek/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: cddb.bundle -- CDDB Bundle for GNUstep
Frank Küster wrote: > Graham Wilson <[EMAIL PROTECTED]> schrieb: > > > On Mon, Oct 04, 2004 at 05:27:59PM +0200, Frank Küster wrote: > >> Seo Sanghyeon <[EMAIL PROTECTED]> schrieb: > >> > For example, "camera" package name was changed to "camera.app" to > >> > prevent namespace pollution. Are you saying that it should be > >> > "gnustep-camera.app"? If so, why? > >> > >> I don't mind what it's called as long as I can see by its name that > >> it is useless without gnustep. In other words: There has to be the > >> string "gnustep" in its name, preferably at the beginning. > > > > What about nautlius? evolution? epiphany? Do they have to have to > > start with gnome-, so that I know there useless without GNOME > > installed? Are they really useless without a complete GNOME > > environment installed? > > I never used nautilus or epiphany. I used evolution (in woody), but > dropped it because it didn't seem to behave deterministic... > > Anyway, I think it depends on what one means with "GNOME installed". I > don't mind having some libraries for Gnome around (actually I use > gnumeric), but for sure I do not want the Gnome desktop. > > But if I remember correctly, GNUstep applications do not just work if > X11 and some basic library is installed, but need the GNUstep desktop to > be installed. With Gnome and KDE, I had the impression that it was > intended that all applications are usable even without using the Desktop > environment - although of course they might work and interact nicer in > their "native" environment. With GNUstep, it seemed to me that it was > not intended to run applications without the Desktop > environment. Comparable to WindowMaker Dock applications, which probably > will not run under any other windowmanager. > > If I'm wrong, I apologize and will not object against cddb.bundle (at > least not because of this. Still the ".bundle" part is meaningless to > me, but that might be due to my bad english). If I am not wrong, and > GNUstep applications are indeed not designed to be used without using > the Desktop environment, then, please, add "gnustep-" to the name. Yes, you are _very_ clearly wrong. There is no GNUstep program that requires the GNUstep Desktop, because there no GNUstep Desktop to require! >From the user's perspective, GNUstep is basically a set of libs and some directory hierarchy imposed by the requirements of the specifications GNUstep implements. That's it. The libs provide a pretty platform-independant library of non-GUI classes, and a fairly-well-working library of GUI classes that is partially window-system independant (i.e. the only GUI backends that work completely are for X, but there's one for Windows GDI that isn't too evil). GNUstep does not form a desktop environment, and it doesn't even claim to
Re: ITP: cddb.bundle -- CDDB Bundle for GNUstep
Frank Küster wrote: > Jeff Teunissen <[EMAIL PROTECTED]> wrote: > > > Frank Küster wrote: > > > >> If I'm wrong, I apologize and will not object against cddb.bundle (at > >> least not because of this. Still the ".bundle" part is meaningless to > >> me, but that might be due to my bad english). If I am not wrong, and > >> GNUstep applications are indeed not designed to be used without using > >> the Desktop environment, then, please, add "gnustep-" to the name. > > > > Yes, you are _very_ clearly wrong. There is no GNUstep program that > > requires the GNUstep Desktop, because there no GNUstep Desktop to > > require! > > Okay, then I don't mind leaving gnustep out (I still wonder why you > wouldn't cry "But I want gnustep in the name" for advertising > reasons). For me, I don't want GNUstep in the names of my programs because I am not connected to GNUstep and don't want to be. It is just a couple of libraries that I use to write my apps -- you wouldn't put "GTK+" in the name of your apps, would you? > I still wonder what "bundle" could mean... At its most basic, a "bundle" is a directory with a certain structure. An .app is a bundle, as are an .rtfd document and a .framework library. An app is a bundle that contains an application (complete with its resources, like images, property list files, text data used by the app, etc.). An RTFD is a compound-document bundle containing an RTF file and usually some image files. A Framework is a bundle containing a special shlib, headers, and resources (executables, images, etc.) In this case, CDDB.bundle is just your basic "loadable bundle", containing code and/or resources that can be loaded into an app using the NSBundle interface. This one provides code in the form of a class to query a cddb server. By the way, .prefs modules (used by Preferences, preferences.app in Debian and one of my apps) are bundles too. -- | Jeff Teunissen -=- Pres., Dusk To Dawn Computing -=- deek @ d2dc.net | GPG: 1024D/9840105A 7102 808A 7733 C2F3 097B 161B 9222 DAB8 9840 105A | Core developer, The QuakeForge Projecthttp://www.quakeforge.net/ | Specializing in Debian GNU/Linux http://www.d2dc.net/~deek/
Re: Re: ITP: cddb.bundle -- CDDB Bundle for GNUstep
Miles Bader wrote: > Jeff Teunissen <[EMAIL PROTECTED]> writes: > > For me, I don't want GNUstep in the names of my programs because I am > > not connected to GNUstep and don't want to be. It is just a couple of > > libraries that I use to write my apps -- you wouldn't put "GTK+" in > > the name of your apps, would you? > > Most GTK+ apps don't need any kind of special tag because they're named > reasonably in the first place. The upstream developers apparently > recognize that they will be often used as one part of a "mixed" > system. And developers writing with GNUstep recognize the same thing. The difference is that we *have* to give enough information about an app using only two pieces of information -- the name of the app and its icon. Because of that _necessary_ restriction, we come up with names that are: 1. Not used by ANY other free software project, 2. Descriptive of what the application does, 3. "Iconable" (an icon can be created that fits with its name) And that is about the extent of the decision-making process. > Many "gnustep" apps OTOH, use absurdly generic names, and I can only > conclude that the developers do not think about mixed systems at all. I disagree in the first case, and you are incorrect in the second. > It is this upstream flaw that forces these apps to have their names > changed in Debian. A shame for true fans of those applications, I > suppose, but what else can you expect? What "forces" the names to be changed is some kind of requirement, not in any foundation document nor in Policy, that the names of packages must be "fair", and that we must protect people from "having to" install a couple of GNUstep libraries when they select a package that they might like. -- | Jeff Teunissen -=- Pres., Dusk To Dawn Computing -=- deek @ d2dc.net | GPG: 1024D/9840105A 7102 808A 7733 C2F3 097B 161B 9222 DAB8 9840 105A | Core developer, The QuakeForge Projecthttp://www.quakeforge.net/ | Specializing in Debian GNU/Linux http://www.d2dc.net/~deek/
Re: Re: Re: ITP: cddb.bundle -- CDDB Bundle for GNUstep
(Note: I'm not subscribed to -devel, only -private and d-d-a, so please Cc me on replies -- this text is copied from the web archives, which is the reason the references are gone) Steve Greenland wrote: > On 06-Oct-04, 06:41 (CDT), Jeff Teunissen <[EMAIL PROTECTED]> wrote: > > And developers writing with GNUstep recognize the same thing. The > > difference is that we *have* to give enough information about an app > > using only two pieces of information -- the name of the app and its > > icon. > > "*Have*" to? Why? Because those are the only bits of meta-info available for programs on an OpenStep-compliant system. OpenStep intentionally does not provide for a program menu including additional metadata, instead using certain well-known directories that you browse in a file manager. > Other applications manage to provide unique names. So do we. The names for GNUstep-based programs ARE unique -- no other free software is using (or, to my knowledge, has ever used) those names, and the names that "conflict" are named as they are for descriptiveness and for compatibility (Terminal, Preferences). As for those names, Terminal and Preferences are named after (and are reimplementations of) programs NeXT created for their NeXTstep operating system, and as such they are important for interoperability. There needs to be a program called "Terminal" responding under that name to the distributed-objects (DO) system, so that other programs can spawn (and optionally control) a new shell (or just a program) in one of its windows. We couldn't just name it something merely similar -- that would break the API (where names for things are significant). One of the things I'll be working on at some point will be an xterm-like client interface (operating via DO) to Terminal to act as an x-terminal-emulator alternative -- precisely BECAUSE we think operating in a mixed environment is important. It'll probably be called bbterm or something similar. > Why does being a GNUstep application give you the right to claim generic > names like "mail", "editor", etc. False argument. None of those names have been used by GNUstep-based apps, and no one has posited any such "right". > Claiming necessity doesn't make it so. If it's simply a convention > of the GNUstep developer's, then your claim to have considered mixed > systems is bogus. It's not merely a convention, it's something that falls out of the spec that GNUstep implements and something that we have to live with. > Note that I'm not promoting the idea that all GNUstep packages names > must begin with "gnustep-". I find the ".app" convention sufficiently > clear; in fact, I assume pretty much anthing with a "." in it's name > GNUstep. To be fair, not all ".app" programs/packages are created using GNUstep, but AFAIK all of them are intended to be used with it (or with a part of it, like Window Maker). > If we are going to allow generic names, then obviously they would be > applied to the most commonly used or "best for the novice" example, so > I'm pretty sure that GNUstep apps aren't going to get them. On one of those counts, many GNUstep-using apps often win over their "competition". e.g. Terminal is a _very_ nice terminal emulator with excellent compatibility (it does UTF-8 well, and emulates the Linux console very well) and many features that are not found elsewhere. TextEdit is a rather good plaintext/RTF text editor, modulo some bugs in the GNUstep libraries. -- | Jeff Teunissen -=- Pres., Dusk To Dawn Computing -=- deek @ d2dc.net | GPG: 1024D/9840105A 7102 808A 7733 C2F3 097B 161B 9222 DAB8 9840 105A | Core developer, The QuakeForge Projecthttp://www.quakeforge.net/ | Specializing in Debian GNU/Linux http://www.d2dc.net/~deek/
Re: ITP: cddb.bundle -- CDDB Bundle for GNUstep
Petri Latvala wrote: [fixing attributions] > On Thu, 2004-10-07 at 09:20, Jeff Teunissen wrote: > > [Steve Greenland wrote:] > > > On 06-Oct-04, 06:41 (CDT), Jeff Teunissen <[EMAIL PROTECTED]> wrote: > > > > And developers writing with GNUstep recognize the same thing. The > > > > difference is that we *have* to give enough information about an > > > > app using only two pieces of information -- the name of the app > > > > and its icon. > > > > > > "*Have*" to? Why? > > > > Because those are the only bits of meta-info available for programs on > > an OpenStep-compliant system. OpenStep intentionally does not provide > > for a program menu including additional metadata, instead using > > certain well-known directories that you browse in a file manager. > > Executable names (or other file names) and Debian package names can > differ. Or does an OpenStep-compliant system search the dpkg database? We weren't talking about package names, we were talking about program names. I don't have problems with the standard Debian naming scheme for packages using GNUstep libs -- *.app, *.framework, *.bundle, etc. It's a bit silly (why do users need to be protected from "unknowingly" installing GNUstep libs?), but it doesn't bug me. What DOES bug me is mindlessly adding "gnustep-" to the names of all packages that use it, because most of the developers of those packages have dick to do with some mythical GNUstep desktop, which itself does not exist. In addition to Debian and QuakeForge, I'm involved in a project to create a user environment that happens to use the GNUstep libraries. That project is called Backbone, and most of what we have done so far is included in Debian (the packages preferences.app, terminal.app, and textedit.app). We're not GNUstep. One of us is also a member of the GNUstep project, but that's not particularly relevant. Why should packages that are part of the Backbone "desktop" (I use quotes because putting a desktop on the root menu makes no sense from our perspective), or packages that are simply useful (or not) programs that use the GNUstep libraries, be advertised as being "GNUstep programs"? That's silly. -- | Jeff Teunissen -=- Pres., Dusk To Dawn Computing -=- deek @ d2dc.net | GPG: 1024D/9840105A 7102 808A 7733 C2F3 097B 161B 9222 DAB8 9840 105A | Core developer, The QuakeForge Projecthttp://www.quakeforge.net/ | Specializing in Debian GNU/Linux http://www.d2dc.net/~deek/
Re: Terminal - a good terminal?
Eduard Bloch wrote: > > #include > * Jeff Teunissen [Thu, Oct 07 2004, 02:20:31AM]: > > > > If we are going to allow generic names, then obviously they would be > > > applied to the most commonly used or "best for the novice" example, > > > so I'm pretty sure that GNUstep apps aren't going to get them. > > > > On one of those counts, many GNUstep-using apps often win over their > > "competition". e.g. Terminal is a _very_ nice terminal emulator with > > excellent compatibility (it does UTF-8 well, and emulates the Linux > > console > > Who said that the "linux" console is a good kind of terminal emulation? It's what's expected. We could do just about any other type, including graphics terminals, but TERM=linux is decent and simple. > > very well) and many features that are not found elsewhere. > > Such as? Let's compare. It may be look nice, but is it really good for > daily use?. I just tried version 0.9.4-2.2 and have "mixed feelings" (to > avoid a bad word) after comparing to rxvt-unicode. > > meta-keys in UTF-8 mode? Only after manual configuration. Not true -- OpenStep has an extra modifier key. Command is bound to the Alt_L keysym by default in gnustep-gui. Alternate is by default bound to Alt_R. A different program lets you easily set which keysyms get bound to the various modifiers. Alternate always does "meta". Command usually is grabbed for key equivalents in the menus. The option to set Command as meta overrides this. The option was created because on some configurations the right Alt key changed its keysym to ISO_Level3_Shift or some other such nonsense. On my 104-key I have two Alts and two Commands, so it's all good. > Manpage? None (or not easy to find). Correct. There's no point. > Command line options? No idea, either none or the program reacts insane
Re: ITP: cddb.bundle -- CDDB Bundle for GNUstep
Adeodato Simó wrote: > * Jeff Teunissen [Thu, 07 Oct 2004 03:52:37 -0400]: > > > What DOES bug me is mindlessly adding "gnustep-" to the names of all > > packages that use it, because most of the developers of those packages > > have dick to do with some mythical GNUstep desktop, which itself does > > not exist. > > but note that adding "gnustep-" or "gstep-" as prefix to "these" > packages is/was (from what I've seen so far): > > (a) the preferred solution by a high majority of DD, as to what > benefits most to archive namespace clutter. I've only seen a few highly-vocal people whenever this comes up, and this suggests to me that few people even /care/ -- but those few that do are in violent disagreement. > (b) what can be regarded as most useful for our users (I, at lest, > think it is, and some other people will as well, I hope). I don't really see how it's useful -- it doesn't matter what libs are used by an app. Why should, for example, TalkSoup (an IRC client) be called g[nu]step-talksoup? It's the only program with that name, it's not "generic", it's not part of the GNUstep project, and it's not even written by a member of the GNUstep project. It has a somewhat-different interface, but you expect that from most apps that work on X. So what's the difference? About the most that's reasonable is to stick .app on the end to tell people that it's not run in the usual manner (unless there's a script included to start it up, in which case no differentiation ought to be made). > > In addition to Debian and QuakeForge, I'm involved in a project to > > create a user environment that happens to use the GNUstep libraries. > > That project is called Backbone, and most of what we have done so far > > is included in Debian (the packages preferences.app, terminal.app, and > > textedit.app). > > > > We're not GNUstep. One of us is also a member of the GNUstep project, > > but that's not particularly relevant. > > but there must be a close relationship to GNUstep when you have: > > preferences - GNUstep Preferences application > terminal - Terminal Emulator for GNUstep > textedit.app - Basic text editor for GNUstep Those descriptions are the result of Debian maintainer malfunctions. None of those applications is "for GNUstep"; they're part of, and for, Backbone. So far they still work with vanilla GNUstep, but that will not always be so and we don't feel any need to ensure that. > > Why should packages that are part of the Backbone "desktop" (I use > > quotes because putting a desktop on the root menu makes no sense from > > our perspective), or packages that are simply useful (or not) programs > > that use the GNUstep libraries, be advertised as being "GNUstep > > programs"? That's silly. > > see above. I'd rather see: > > gstep-preferences - GNUstep Preferences application from the > Backbone project > gstep-terminal - Terminal Emulator for GNUstep from the Backbone > project > gstep-textedit - Basic text editor for GNUstep from the Backbone > project And I'd rather see: backbone - Dependency package for the Backbone user environment backbone-sysapps - Core applications for Backbone backbone-sysframeworks - Core frameworks for Backbone backbone-systools - Core utilities for Backbone backbone-* (a la carte things from the currently-empty Common set) where -sysapps contains Preferences, Terminal, TextEdit, and eventually our workspace manager; -systools contains open, the openapp diversion, bbterm, and "panel" (a command-line program for popping up various types of panels [dialog boxes] -- this may not be what it is eventually called, of course); and -sysframeworks contains the PrefsModule and HelpPanel frameworks. That would be the Backbone System (equivalent to the GNOME or KDE core), which we plan to make more integrated over time. Additionally, we'll have other sections for optional components (much like Debian's optional and extra priorities) which can be cherry-picked. [snip] > [btw, the mail I'm replying to is the *first* (that I can find) > containing the "Backbone" word. if this had been mentioned earlier, > I'm sure it would had made people happier packages with names like > backbone-$whatever or $whatever-backbone that the current $foo.app.] Take that up with the Debian maintainers of the Backbone packages. While I am a DD, I have nothing to do with their packaging (since all of the GNUstep stuff I have is source-built and usually from cvs, I wouldn't be using my own packages). -- | Jeff Teunissen -=- Pres., Dusk To Dawn Computing -=- deek @ d2dc.net | GPG: 1024D/9840105A 7102 808A 7733 C2F3 097B 161B 9222 DAB8 9840 105A | Core developer, The QuakeForge Projecthttp://www.quakeforge.net/ | Specializing in Debian GNU/Linux http://www.d2dc.net/~deek/
Re: Terminal - a good terminal?
Eduard Bloch wrote: > * Jeff Teunissen [Thu, Oct 07 2004, 09:10:56AM]: [snip] > > > Who said that the "linux" console is a good kind of terminal > > > emulation? > > > > It's what's expected. > > By whom? By people who spend a lot of time at the console? > > We could do just about any other type, including graphics terminals, > > but TERM=linux is decent and simple. > > And primitive. And unuseable or not so comfortable when opening a shell > on non-Linux system. Primitive? heh. And as for the rest, I haven't had trouble -- it's just an infocmp away. In any case, switching the emulation is trivial -- it's not like terminal emulation is complicated. > > > meta-keys in UTF-8 mode? Only after manual configuration. > > > > Not true -- OpenStep has an extra modifier key. > > > > Command is bound to the Alt_L keysym by default in gnustep-gui. > > Alternate is by default bound to Alt_R. A different program lets you > > easily set which keysyms get bound to the various modifiers. > > > > Alternate always does "meta". Command usually is grabbed for key > > equivalents in the menus. The option to set Command as meta overrides > > this. The option was created because on some configurations the right > > Alt key changed its keysym to ISO_Level3_Shift or some other such > > nonsense. > > I do not know which nonsence you mean but I do not have something > special, just default Debian GNU/Linux environment and there it did not > work. I had to set this switch. Yeah, it was implemented for broken environments. ( /me grins and hides from overfiend :) ) Did you try using the right Alt key? If you did try it and it didn't work, then X isn't reporting it as Alt_R, so -gui isn't telling the app that the Alternate modifier is set. Again, it's not an X program, it just happens to work when rigged with a GUI backend that uses X. And there's no such thing as a "default" X config. [snip] > It does not print anything useful when executed with -h or --help. It > just ignores these options, that is not a very userfriendly behaviour, > IMHO. Because you're not supposed to execute it directly -- that's why it's not in the PATH. There are plenty of options when creating a new window, but they are not available from the commandline (and won't be, until I create the tool to exercise them). [snip] > > > UTF-8 support? Lousy or none. One has to choose it manually (and it > > > supports only few encoding anyways). > > > > It can support more by just adding a couple of lines to the popup > > button; GNUstep does all of its string handling in UTF-16 internally. > > Add more? It does not support UTF-8 well. It supports UTF-8 fine, as long as it can get the glyphs. [snip] > Yeah. And a sane Unicode compatible terminal would try fallback to > similar fonts. That is what Rxvt-Unicode or Gnome-Terminal do. Of course > you can use the "missing in this font" excuse, but then you should made > at least the font selector work. Currently, I see only four fonts there, > and the selecting another one is either not stored, or has no effect. I only get a few bad-glyph markers when I cat the UTF-8-demo. Well, except for the Ethiopian sample, for which my 10646-1 terminal font has no glyphs. And it's not the terminal, it's the GNUstep GUI backend (gnustep-back) that's failing to do glyph substitution and coercion. Of course, there are problems with font substitution that make it a pain in the ass when you have a PostScript display model. e.g. since it's supposed to be WYSIWYG throughout, doing substitution in the app isn't always going to result in the same thing going onto the paper, so to DTRT means a lot more work. But hey, who cares about that? I WANT MY TEXT. It's not my fault that or whoever did the font setup for gnustep-back didn't set the default fixed-width font to something reasonable for Unicode...but then, the default character coding is Latin 1. > > The ART backend graphics target's glyph generator doesn't currently do > > glyph combining or font substitution, though the latter is apparently > > in progress. > > Then please don't call it UTF-8 capable before it really supports most > of it. It does, and many other Unicode systems don't handle UTF-8 glyph-combining either. But it's being worked on. > > > Choosing the "Handle widht-chars" option has broken the output > > > completely. > > > > Works here, what backend and font were you using? > > What is a "backend"? I just assumed what other people said and started > it with defaults. Well,
Re: Re: Terminal - a good terminal?
[ I'm not subbed to -devel, this was pulled from the archive -- please Cc me on replies ] Thomas Dickey wrote: > Jeff Teunissen <[EMAIL PROTECTED]> wrote: > > > Primitive? heh. And as for the rest, I haven't had trouble -- it's > > just an infocmp away. In any case, switching the emulation is trivial > > -- it's not like terminal emulation is complicated. > > Judging by the variety of poor implementations, I'd say that's > incorrect. Even "linux" emulation - how many implement its savable > colors? Well, at least one does. :) A lot of our main emulation code was culled from the kernel source, and abstracted some. So we got most of it for free, and the rest is just doing a few things that aren't implemented by the kernel. So yeah, "setterm -*ground foo -store" works. -- | Jeff Teunissen -=- Pres., Dusk To Dawn Computing -=- deek @ d2dc.net | GPG: 1024D/9840105A 7102 808A 7733 C2F3 097B 161B 9222 DAB8 9840 105A | Core developer, The QuakeForge Projecthttp://www.quakeforge.net/ | Specializing in Debian GNU/Linux http://www.d2dc.net/~deek/
Re: Re: Terminal - a good terminal?
[ I'm not subbed to -devel, this was pulled from the archive -- please Cc me on replies ] Thomas Dickey wrote: > Jeff Teunissen <[EMAIL PROTECTED]> wrote: > > > Primitive? heh. And as for the rest, I haven't had trouble -- it's > > just an infocmp away. In any case, switching the emulation is trivial > > -- it's not like terminal emulation is complicated. > > Judging by the variety of poor implementations, I'd say that's > incorrect. Even "linux" emulation - how many implement its savable > colors? Well, at least one does. :) A lot of our main emulation code was culled from the kernel source, and abstracted some. So we got most of it for free, and the rest is just doing a few things that aren't implemented by the kernel. So yeah, "setterm -*ground foo -store" works. -- | Jeff Teunissen -=- Pres., Dusk To Dawn Computing -=- deek @ d2dc.net | GPG: 1024D/9840105A 7102 808A 7733 C2F3 097B 161B 9222 DAB8 9840 105A | Core developer, The QuakeForge Projecthttp://www.quakeforge.net/ | Specializing in Debian GNU/Linux http://www.d2dc.net/~deek/
Re: Re: Terminal - a good terminal?
[ I'm not subbed to -devel, this was pulled from the archive -- please Cc me on replies ] Thomas Dickey wrote: > Jeff Teunissen <[EMAIL PROTECTED]> wrote: > > > Primitive? heh. And as for the rest, I haven't had trouble -- it's > > just an infocmp away. In any case, switching the emulation is trivial > > -- it's not like terminal emulation is complicated. > > Judging by the variety of poor implementations, I'd say that's > incorrect. Even "linux" emulation - how many implement its savable > colors? Well, at least one does. :) A lot of our main emulation code was culled from the kernel source, and abstracted some. So we got most of it for free, and the rest is just doing a few things that aren't implemented by the kernel. So yeah, "setterm -*ground foo -store" works. -- | Jeff Teunissen -=- Pres., Dusk To Dawn Computing -=- deek @ d2dc.net | GPG: 1024D/9840105A 7102 808A 7733 C2F3 097B 161B 9222 DAB8 9840 105A | Core developer, The QuakeForge Projecthttp://www.quakeforge.net/ | Specializing in Debian GNU/Linux http://www.d2dc.net/~deek/
Re: quake I for woody
Joey Hess wrote: > > Jeff, unless I'm mistaken you've taken over maintainence of the debian > packaging of quakeforge and you have fairly current packaging in the > quakeforge-current tree in their cvs. I remember that when knghtbrd > decided to remove quakeforge packages from debian, it was because of > technical problems with the state of the quakeforge codebase, and, it > seemed to me, because of political type problems as well. Yeah, I'm doing the Debian stuff, at least within QuakeForge. There are two problems with the packages; the lack of menus, and the problems with handling default sound output. I could make the default null, but then most people will think that QuakeForge doesn't have sound. Last thing I did was use alternatives to provide a "default" sound plugin, which worked nicely, but then we did some nasty things to plugin symbols which allowed people to statically link all of them into the main executables. Runs faster, but you can't load a plugin with a different name any more. Looks like it's time for debconf, I suppose. > Years ago, I used to maintain those non-free, binary-only packages, and > I didn't pass on maintainence with the expectation that quake would be > removed from the archive entirely later down the line. I would rather > see those nasty old packages copied from hamm (or was it rexx) woody bo, I think. [snip] > [1] Which don't seem fully resolved to me; they're still merging > code and have not produced an easily usable game with nicities > like menus). But maybe it's usable and just hard to use, which > documentation can solve well enough. Not unusable, but arcane to someone who is new to Quake or isn't used to dealing without menus. e.g. new game: map start invert mouse: m_pitch "-0.022" normal mouse: m_pitch "0.022" > [2] Or main, if Ben insists. And yeah, if necessary, I'm volenteering, > though I'd not be able to give it the time it probably requires. I don't really think it could be in main at this point. -- | Jeff Teunissen -=- Pres., Dusk To Dawn Computing -=- deek @ d2dc.net | GPG: 1024D/9840105A 7102 808A 7733 C2F3 097B 161B 9222 DAB8 9840 105A | Core developer, The QuakeForge Projecthttp://www.quakeforge.net/ | Specializing in Debian GNU/Linux http://www.d2dc.net/~deek/
Re: quake I for woody
Joseph Carter wrote: > > On Mon, Dec 31, 2001 at 07:02:43AM -0500, Jeff Teunissen wrote: > > > Jeff, unless I'm mistaken you've taken over maintainence of the > > > debian packaging of quakeforge and you have fairly current packaging > > > in the quakeforge-current tree in their cvs. I remember that when > > > knghtbrd decided to remove quakeforge packages from debian, it was > > > because of technical problems with the state of the quakeforge > > > codebase, and, it seemed to me, because of political type problems > > > as well. > > > > Yeah, I'm doing the Debian stuff, at least within QuakeForge. > > The stuff outside I have done. Back in March or so I designed a nice, > complex, and complete system for handling gamedata. It would work as > long as an engine using it had fs_* Cvars and config files. Unless of > course you did something unexpected in your config file, in which case > it puked. Too fancy, and it broke. Solution without a problem. Game data must keep its name, and both registered and unregistered Quake game data always has to be in id1. [snip] > I can actually do the necessary work to get the shareware thing done > next weekend (I'm going on holiday for a few days and won't have much > time for code..) As for the registered game installer, I've got > something written in perl for that already, but it's not much and it > comes with a big warning that perl is not a language I actually grok. I have had a quake-shareware package ready for upload since I needed one to finish the QF packages, about 3 months ago as I remember it. It's at my apt repo, alongside the (~1 month old) QF packages that depend on it. -- | Jeff Teunissen -=- Pres., Dusk To Dawn Computing -=- deek @ d2dc.net | GPG: 1024D/9840105A 7102 808A 7733 C2F3 097B 161B 9222 DAB8 9840 105A | Core developer, The QuakeForge Projecthttp://www.quakeforge.net/ | Specializing in Debian GNU/Linux http://www.d2dc.net/~deek/
Re: APRIS GNU/LINUX EXPO UPDATES. (need debian Logo).
Wichert Akkerman wrote: > > Previously Frederic CELLA wrote: > > can i send to them ? (this one the fisrt page of www.debian.org) > > The webpage has a postscript version of the logo iirc. This should make > it trivial for them to produce a 300dpi logo (or whatever other > resolution they desire). Speaking of the open use logo, was it intentional or an unintentional artifact of the conversion from EPS to xfig that changed the shape of the letters and the logo itself? I find that raul's original logos seem to have much nicer shapes, particularly that of the Swirl itself. The xfig conversions have a strange bulge in the lower-left quadraint, and the letters have more quared-off corners to them. For example, compare http://www.debian.org/logos/ with http://dusknet.dhis.org/~deek/debian/ -- In the latter page, the letters were converted from Raul's EPS to Gimp XCF directly. Note: The color change to the darker red was my doing, but nothing else has been changed -- I still have original-colored pristine EPS and XCF sources, if anyone wants them. -- | Jeff Teunissen -- President, Dusk To Dawn Computing -- [EMAIL PROTECTED] | Disclaimer: I am my employer, so anything I say goes for me too. :) | dusknet.ddns.org is a black hole for email.Use my Reply-To address. | Specializing in Debian GNU/Linux http://dusknet.dhis.org/~deek/
