From: Alan S. <ala...@po...> - 2003-05-25 15:33:26
|
Hi, While browsing this morning I found this history of Object Desktop, which might interest you if you're into the desktop customization thing: http://www.stardock.com/stardock/articles/article_odhistory.html Thinking a bit about all this, I was wondering about the future of XFree in relation to eye candy that can now be found on Mac OS X for instance. If I understand how it works, the OSX graphic engine keeps a bitmap of every window, which lets it do real transparency. On the other hand, XFree only remember what's on the screen, and asks the apps (using resize or expose events) to draw on the screen when something changes. It requires less memory, but prevents parts of windows that are not exposed to modify what's on the screen (and it seems to make programming more complex, as the program needs to remember what's supposed to be on the screen to redraw it when exposed). I guess that people are going to want true transparency for X some day, as well as eye candy such as repainting of the pager small pictures for other desktops ... So I'm wondering whether X may evolve to a "keep a bitmap of all windows" model, or if it's too big a change and some other system will replace it. Any thoughts ? Alan Schmitt PS: on some related note, Brad Wardell said that the closest thing to Object Desktop that exists on Linux is Enlightenment ;-) -- The hacker: someone who figured things out and made something cool happen. |
From: <Val...@vt...> - 2003-05-25 19:29:11
|
On Sun, 25 May 2003 11:31:47 EDT, Alan Schmitt <ala...@po...> said: > other desktops ... So I'm wondering whether X may evolve to a "keep a > bitmap of all windows" model, or if it's too big a change and some other > system will replace it. Any thoughts ? You can get to the "keep all bitmaps' model fairly easily by simply enabling "backing store" and/or "save unders" on the server (although there's not *guarantee* that the server will actually do it, usually). A bigger problem is that it's actually harder than you think to get the semantics of this sort of thing right and get something usable. Two examples: 1) We currently have pseudo-transparent Eterms that you can park on your desktop and get the effect of text floating on the desktop. However, this does *NOT* extend to the general case - if you park several of them above each other in an overlapping fashion, they're not *really* transparent. This is probably a Good Thing - otherwise, you'd get an unreadable mess. You get to deal with a lot of performance-messy stuff - for instance, if you are using anti-aliased text and have (say) 2 Eterms stacked, to do it right you need to take the bottom Eterm, composite its background and whatever is under it, apply the text anti-aliasing to THAT pixmap, then use that to composite to the upper Eterm's background and then apply anti-aliased text to THAT result. Painful enough? Now scroll the lower Eterm up a line. Have a nice day. ;) 2) Usually, "transparency" is linked to "we want drop shadows", which is actually a different issue. Transparency, you have pixels depending on what's below them on the screen. Drop shadows, you have the issue that if your drop shadow is (say) 10 pixels wide and the window is transparent, then the actual value of a pixel 8 pixels below/outside the "upper" window is now dependent on the pixel value 2 pixels inside the window. That's bad enough, but now let's put another transparent window with its upper edge just 3 pixels below the other upper window - so you have to take the first window, compute its shadow, put that onto the second window, and then bring that up through the other transparent window. Now hit the keystroke that does a raise/lower in the stacking order. Have a nice day.. ;) OSX manages to deal with most of these corner cases because it's fairly fascist - it imposes policy on the apps. X could probably do it too, but it would have to be very careful to avoid breaking the "we don't do policy" mindset. And remember that "we don't do policy" is the only reason why Enlightenment can exist at all..... |
From: Lyle K. <te...@tw...> - 2003-05-25 20:22:55
|
This reply isn't really directed at you so much as directed at several arguments I hear recurring from time to time.. * Val...@vt... (Val...@vt...) wrote: > On Sun, 25 May 2003 11:31:47 EDT, Alan Schmitt <ala...@po...> said: > > > other desktops ... So I'm wondering whether X may evolve to a "keep a > > bitmap of all windows" model, or if it's too big a change and some other > > system will replace it. Any thoughts ? > > You can get to the "keep all bitmaps' model fairly easily by simply enabling > "backing store" and/or "save unders" on the server (although there's not > *guarantee* that the server will actually do it, usually). > > A bigger problem is that it's actually harder than you think to get the > semantics of this sort of thing right and get something usable. Two examples: > > 1) We currently have pseudo-transparent Eterms that you can park on your > desktop and get the effect of text floating on the desktop. However, this > does *NOT* extend to the general case - if you park several of them above > each other in an overlapping fashion, they're not *really* transparent. > This is probably a Good Thing - otherwise, you'd get an unreadable mess. I have never agreed with this. If you apply some rule of opacity for each window section back from the front a section is, eventually it is only apparent there's more content behind it, but it's blurry or otherwise not text-like enough that it's in the way. > You get to deal with a lot of performance-messy stuff - for instance, if you > are using anti-aliased text and have (say) 2 Eterms stacked, to do it right > you need to take the bottom Eterm, composite its background and whatever is > under it, apply the text anti-aliasing to THAT pixmap, then use that to > composite to the upper Eterm's background and then apply anti-aliased text > to THAT result. Painful enough? > > Now scroll the lower Eterm up a line. Have a nice day. ;) I don't like this attitude, either. These are the sorts of problems game developers have faced, which is why cards provide the functionality required to do this fast. The software we use on our displays should be expanding or otherwise moving towards supporting the features its users want to see. That's the nature of a useful program, it continues to provide what people want from it. Otherwise, you get things like code forks, or dead projects. This is a problem I see with X development lately, which is why the very public debacle that just occured within the XF organization was probably a good thing for everyone, in the long run. > 2) Usually, "transparency" is linked to "we want drop shadows", which is > actually a different issue. Transparency, you have pixels depending on > what's below them on the screen. Drop shadows, you have the issue that > if your drop shadow is (say) 10 pixels wide and the window is transparent, > then the actual value of a pixel 8 pixels below/outside the "upper" window is now > dependent on the pixel value 2 pixels inside the window. That's bad enough, > but now let's put another transparent window with its upper edge just 3 > pixels below the other upper window - so you have to take the first window, > compute its shadow, put that onto the second window, and then bring that > up through the other transparent window. I also rarely hear people wanting drop shadows more than real transparency as OSX implements it (or, as you say, Eterm pretends to implement it). :) > Now hit the keystroke that does a raise/lower in the stacking order. Have > a nice day.. ;) > > OSX manages to deal with most of these corner cases because it's fairly > fascist - it imposes policy on the apps. X could probably do it too, but > it would have to be very careful to avoid breaking the "we don't do policy" > mindset. And remember that "we don't do policy" is the only reason why > Enlightenment can exist at all..... Agreed, but we need improvements. Other graphics architectures (Longhorn, OSX, etc) are beginning once again to take the cutting edge away from projects like Enlightenment, and in part it's because the project has had to invent its own additional layers (which have taken a long time and have happened as the developers involved have all transitioned to new jobs, etc) in order to catch up. Hence, ecore, evas, edb. Some would argue that we could do without them, but really, we shouldn't -- other graphics architectures have the same sorts of APIs. In my opinion, the need for raster to write these APIs in part stems from a culture surrounding X that we can't deem outdated features or architecture as such and perform real innovation. Maybe I'm alone in that view, but it is a view I have. term |
From: <Val...@vt...> - 2003-05-26 03:37:11
|
On Sun, 25 May 2003 15:18:12 CDT, Lyle Kempler <te...@tw...> said: > I have never agreed with this. If you apply some rule of opacity for > each window section back from the front a section is, eventually it is > only apparent there's more content behind it, but it's blurry or > otherwise not text-like enough that it's in the way. Well, yeah. *SURE* if the system puts its foot down and says "the alpha can't be less than 0.85" it works. That's policy though. ;) > In my opinion, the need for raster to write these APIs in part stems > from a culture surrounding X that we can't deem outdated features or > architecture as such and perform real innovation. Maybe I'm alone in > that view, but it is a view I have. There's a hell of a lot to be said for backward compatibility. You can take an X11 application from Solaris to Linux to Tru64 to AIX, even if you do have to port some libraries first. Now try porting your Berlin application to anything else. Or port anything else to Berlin. :) |
From: Lyle K. <te...@tw...> - 2003-05-26 05:23:59
|
* Val...@vt... (Val...@vt...) wrote: > On Sun, 25 May 2003 15:18:12 CDT, Lyle Kempler <te...@tw...> said: > > I have never agreed with this. If you apply some rule of opacity for > > each window section back from the front a section is, eventually it is > > only apparent there's more content behind it, but it's blurry or > > otherwise not text-like enough that it's in the way. > Well, yeah. *SURE* if the system puts its foot down and says "the > alpha can't be less than 0.85" it works. That's policy though. ;) X simply needs to provide a direct or nearly-direct set of calls to do it, which it doesn't right now. Policy doesn't really enter into it; though it would be nice to be able to grab the default levels from a central location (Xresources, etc). > > In my opinion, the need for raster to write these APIs in part stems > > from a culture surrounding X that we can't deem outdated features or > > architecture as such and perform real innovation. Maybe I'm alone in > > that view, but it is a view I have. > There's a hell of a lot to be said for backward compatibility. > > You can take an X11 application from Solaris to Linux to Tru64 to AIX, > even if you do have to port some libraries first. There's a reason the slogan for E is "It's time to rethink everything." The goal here is to innovate, and sometimes that means realizing that while backward compatibility is nice, it can stand in the way. When it does, it should be tossed by the wayside, or in this case, I think emulated. X11 servers tend to have an X10 implementation (I'm fairly sure XF86 does), right? I've often wondered why no one maps an X11 implementation onto an X12 prototype, etc. Innovating doesn't have to mean never being able to support the past -- but it does mean, at some point, having to accept that it is, in fact, a past technology, and state of the art has moved forward. > Now try porting your Berlin application to anything else. Or port > anything else to Berlin. :) Berlin's mistake was trying to be too different, and it's often a hard route to take. Entrenchment or wide deployment usually means that innovations have to be eased in. Take how VFS changes in the Linux kernel have come about: slowly, methodically, and carefully. The innovations occured, while it remained pretty rock-solid overall, and yet the changes built on what was already done in a way that there wasn't massive rejection. Berlin is more like CML2; big, confusing, and largely a lot of idealism instead of a lot of pragmatism. So it was rejected and shunned. Not many people are using Berlin, and its utility is pretty questionable. Anyway, my point in saying all of this is to point out that wanting transparency and a few whizbang new features like it really isn't all that unreasonable with technology where it is.. but when pressed about it, I see arguments amounting to "it's non-trivial" and then later "but what we have works fine". Raster's reason for not allowing transparency in his programs as of late has nothing to do with not wanting to provide the feature, but everything to do with not having to work around the underlying technology. It's the wrong way to do it, and until enough people demand that underlying technology be updated, it isn't going to change. And last I checked, XRender didn't provide a fast enough path to trounce Evas.. term |
From: <Val...@vt...> - 2003-05-26 18:02:58
|
On Mon, 26 May 2003 00:22:57 CDT, Lyle Kempler <te...@tw...> said: (Let me point out for starters that if I had objections to the *idea* of eye candy, I'd not be running the Ganymede theme... Also, remember that for much of this, I'm not explaining *my* viewpoint, but the viewpoint of the people you're really disagreeing with... ;) > > > I have never agreed with this. If you apply some rule of opacity for > > > each window section back from the front a section is, eventually it is > > > only apparent there's more content behind it, but it's blurry or > > > otherwise not text-like enough that it's in the way. > > Well, yeah. *SURE* if the system puts its foot down and says "the > > alpha can't be less than 0.85" it works. That's policy though. ;) > > X simply needs to provide a direct or nearly-direct set of calls to do > it, which it doesn't right now. Policy doesn't really enter into it; > though it would be nice to be able to grab the default levels from a > central location (Xresources, etc). If you got just a "direct or nearly-direct set of calls", who's applying your hypothetical rule of opacity? This is a serious issue - you yourself admit said rule is needed to make it "work right". Who gets to apply the rule? Traditionally, X doesn't, since it doesn't do policy. But making each and every program do it isn't right either... > emulated. X11 servers tend to have an X10 implementation (I'm fairly > sure XF86 does), right? Wrong. X11 was a completely non-compatible break from X10.4. Any and all X10.4 programs *HAD* to be fixed to even compile under X11. I know, I was there. It wasn't pretty. You're probably thinking of the +bc (bug-compat) switch that allows certain broken X11R1-X11R3 programs to work even though they send bogus values in some fields. > Anyway, my point in saying all of this is to point out that wanting > transparency and a few whizbang new features like it really isn't all > that unreasonable with technology where it is.. but when pressed about > it, I see arguments amounting to "it's non-trivial" and then later "but > what we have works fine". One thing to remember is that a *lot* of the support for X11 comes from the groups that support KDE, Gnome, CDE, and the like - and they have other goals than "just eye candy". The quickest way to get actual activity here would be to do a real, properly run HCI study that showed that proper use of <insert eye candy feature here> actually resulted in a more productive and usable interface. Sure - transparency is neat and slick. But how does it help me churn out more lines of code a day? (Notice that there *is* activity on the anti-aliased fonts scene - mostly because people agree that anti-aliased fonts help a lot of things...) |
From: Lyle K. <te...@tw...> - 2003-05-27 04:43:34
|
* Val...@vt... (Val...@vt...) wrote: > On Mon, 26 May 2003 00:22:57 CDT, Lyle Kempler <te...@tw...> said: > (Let me point out for starters that if I had objections to the *idea* of > eye candy, I'd not be running the Ganymede theme... Also, remember that > for much of this, I'm not explaining *my* viewpoint, but the viewpoint of > the people you're really disagreeing with... ;) Noted. :) > > > > I have never agreed with this. If you apply some rule of opacity for > > > > each window section back from the front a section is, eventually it is > > > > only apparent there's more content behind it, but it's blurry or > > > > otherwise not text-like enough that it's in the way. > > > Well, yeah. *SURE* if the system puts its foot down and says "the > > > alpha can't be less than 0.85" it works. That's policy though. ;) > > X simply needs to provide a direct or nearly-direct set of calls to do > > it, which it doesn't right now. Policy doesn't really enter into it; > > though it would be nice to be able to grab the default levels from a > > central location (Xresources, etc). > If you got just a "direct or nearly-direct set of calls", who's applying your > hypothetical rule of opacity? > > This is a serious issue - you yourself admit said rule is needed to make > it "work right". Who gets to apply the rule? Traditionally, X doesn't, > since it doesn't do policy. But making each and every program do it isn't > right either... Like you say, X's job isn't to apply policy, but to provide a framework for setting policy. The ability to set limits and/or defaults could set by the WM, or by a toolkit. The important thing is to make it possible in the first place. > > emulated. X11 servers tend to have an X10 implementation (I'm fairly > > sure XF86 does), right? > Wrong. X11 was a completely non-compatible break from X10.4. Any and all > X10.4 programs *HAD* to be fixed to even compile under X11. I know, I was > there. It wasn't pretty. You're probably thinking of the +bc (bug-compat) > switch that allows certain broken X11R1-X11R3 programs to work even though > they send bogus values in some fields. I had remembered seeing X10 support in the sources. Not having read further into it, I guess I didn't get a clear picture of what it could do. However, the idea is still sound, of supporting X11 emulated while improving things. Certainly enough of an improved X would cover the same territory where it'd be possible to emulate X11 feasibly. > > Anyway, my point in saying all of this is to point out that wanting > > transparency and a few whizbang new features like it really isn't all > > that unreasonable with technology where it is.. but when pressed about > > it, I see arguments amounting to "it's non-trivial" and then later "but > > what we have works fine". > One thing to remember is that a *lot* of the support for X11 comes from > the groups that support KDE, Gnome, CDE, and the like - and they have other > goals than "just eye candy". The quickest way to get actual activity here > would be to do a real, properly run HCI study that showed that proper use > of <insert eye candy feature here> actually resulted in a more productive > and usable interface. > > Sure - transparency is neat and slick. But how does it help me churn out > more lines of code a day? People play Quake 3 with pretty much every advanced feature turned off, on a slow card. It doesn't really improve game proficiency by having all of those features, so why have them? The argument isn't sound. People like nice things. Why have a black case? Why have a neon light in there? Sometimes you add features because they make the experience more comfortable, more pleasurable, etc. You don't need an HCI study for those. </speech> term |
From: Carsten H. (T. R. <ra...@ra...> - 2003-05-27 05:07:05
|
On Mon, 26 May 2003 23:42:32 -0500 Lyle Kempler <te...@tw...> babbled: > People play Quake 3 with pretty much every advanced feature turned off, > on a slow card. It doesn't really improve game proficiency by having all > of those features, so why have them? > > The argument isn't sound. People like nice things. Why have a black > case? Why have a neon light in there? Sometimes you add features because > they make the experience more comfortable, more pleasurable, etc. You > don't need an HCI study for those. In many ways that's what E is about. not an HCI study of "one size fits all" in terms of UI efficiency - is idea is to make that all configurable and let someone else make those decisions. E & tools are just a great mechanism of getting theme. We may provide a set of defaults - for better or worse they are defaults. some will like, some will hate. that's life. we are here to ENABLE the nice thins, enable the HCI designer, enable the "shadows" "multiple light sources" "high detail" "alpha blending" etc. how an hci expert CHOSES to use these features to express something better or make it a better user experience IMHO is not our place to say - in fact it is only the place of the person designing the gui for a PARTICULAR AUDIENCE in mind - u design for a target audience. we simply make it possible. now if we are going to provide these bells & whistles - i'd like to see them done well, right & cleanly. nasty "fake transparency" hacks imho are just past their time. modern cpu's are fast enough to do a lot of it.. let's not talk about modern gfx chipsets. why do we need to do half-arses lumps of very iffy code (at best) to work around what could & should be done properly. i do not want to - and do not wish to condone it. i'd rather put in palce the mechanisms to enable it and encourage those who can implement it to do so and then slide the features in later under the hood cleanly - without having to account for nasty hacks. -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@de... Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9698 8615 |
From: Ben F. <be...@ka...> - 2003-05-26 06:05:45
Attachments:
smime.p7s
|
Did anyone notice the Tron reference towards the end of the article? Dunno if it was intentional or not ;) -b -- The fundamental difference between Unix and the Macintosh operating system is that Unix was designed to please programmers , whereas the Mac was designed to please users. (Windows, on the other hand, was designed to please accountants, but that's another story.) |
From: Ben F. <be...@ka...> - 2003-05-27 05:52:02
Attachments:
smime.p7s
|
Carsten Haitzler (The Rasterman) wrote: >In many ways that's what E is about. not an HCI study of "one size fits all" in terms of UI efficiency - is idea is to make that all configurable and let someone else make those decisions. E & tools are just a great mechanism of getting theme. > I wish Havoc Pennington and crew understood this concept. . . . anxiously awaiting e17 . . . -b -- The fundamental difference between Unix and the Macintosh operating system is that Unix was designed to please programmers , whereas the Mac was designed to please users. (Windows, on the other hand, was designed to please accountants, but that's another story.) |
From: Carsten H. (T. R. <ra...@ra...> - 2003-05-27 06:19:09
|
On Mon, 26 May 2003 22:50:14 -0700 Ben Ford <be...@ka...> babbled: > Carsten Haitzler (The Rasterman) wrote: > > >In many ways that's what E is about. not an HCI study of "one size fits all" > >in terms of UI efficiency - is idea is to make that all configurable and let > >someone else make those decisions. E & tools are just a great mechanism of > >getting theme. > > > > I wish Havoc Pennington and crew understood this concept. at the start gnome was about being configurable (to a degree) and being better - i know why they have removed configureability now - but i'm not sure it was a good move. but it's their project. we are free to do something else. that's the philosophy down in this small, dark, damp e corner of the world where the moss grows thick and... -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@de... Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9698 8615 |