The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Qt on DirectFB
by AC on Wednesday 27/Aug/2003, @00:13
|
By now I have said this a couple of times on these boards, KDE WILL be doing (several) Microsoft catch ups 'again'. Not many developers really care about this, but it does reveal some bad aspects of how KDE is almost entirely dependant on (often jobless) volunteers. Holding ones breath for features is therefor often routine. Yes it works, but more and more open source projects themselves will have to 'compete' on how they manage themselves.
About Longhorns new GUI, most developers respond with that MS will probably implement Apple GUI features. I believe this is true - to some extend. MS has created a 'new' GDI code-named Aero. I bet allot of research is going into this and the developers are experimenting/toying allot with it. (with research I mean: what animations will help improve the windowing and make it easier to navigate) It will do what DirectFB, X11, Qt only promise to do.
One reaction on this board is: "Do you rely need a jumping OK button?". Such a mindset is so absolutely appalling when it comes to vision and progress of usability! Tell that to some Microsoft developers working on Longhorn and you will look so silly and irrelevant in your green dragon shirt.
I am relatively new to Open Source, but how can KDE ever provide innovations trough _ongoing_ research? Isn't this an inherently impossible thing to do with KDE-Open Source and only possible with solid fundings?
The thing which just 'bothers' me is that now many developers are nay saying and when Longhorn comes out, you bet there will be catching up (again) and then they are stuck with X11 or some hack. Key to the issue is that Microsoft did research and KDE could only do catch up and eventually innovate from its new gained abilities.
Its almost paradoxical, calling an open source desktop superior, while admitting there are shortcomings due to dependence on developer volunteering. Is there such a thing as "KDE research"? And if there is, would it be like KDE-usability, totally dependand on volunteers who seem to update their site 1 time a month (if not half a year)?
Open Source projects could improve in the organization/management beyond the developer organization. I truly believe that and am myself working on projects which are more concentrated on organization/managing of open source projects. The beauty is that these projects are all based on GPL software for web code.
One thing management should ensure is that any developer yelling "Do you rely need a jumping OK button?" will fall flat on his face and will be buried in visionary open source _competition_. Yes it already is that case, but it would be better to have less developers waste less time on pre-doomed mindsets. Key to all this is project alignment.
I believe we will begin seeing a trend where projects will emerge which don't necessarily develop open source code, but who will develop open source "supportive services". Kind of like sourceforge but then stretched to other fields - all serving a supportive role for open source.
Anyway, enough rant here is a possible informative link about Longhorn: http://www.winsupersite.com/showcase/longhorn_preview_2003.asp
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Dawnrider on Wednesday 27/Aug/2003, @02:30
|
With respect, AC, I think you may be overly optimistic about what Longhorn's graphical features will entail.
In the very, very long term, full 3D desktops might be desireable, but that would be in CAVEs and systems capable of offering the user an interactive 3D experience. A monitor is inherently 2D, and with the best will in the world, making each window a surface offers very few advantages. It essentially allows you to do window effects. If you look at OSX, you'll see clearly that it is used to shrink the window to a thumbnail in real time (looks like the window is being poured down a funnel) and a few other things, all of which are eye candy, and that is the most evident example. In fact, the only Quartz effect I have ever seen that is useful is the one in Panther, where you can shrink your windows on the desktop, so that you can zoom out and get a better look at all your work. Even this is of limited used, since the OSX gui limits users who want to open large numbers of windows and Quartz itself cripples the machine with large numbers of windows, simply because it allocates a full framebuffer-sized chunk of memory per window. Longhorn essentially wants to be able to play around with windows in the same way as OSX, with fancy effects. It isn't a productivity improvement or usability enhancement for the most part (the zooming being the only exception).
Moreover, if you look at Longhorn, their other features are:
- The bar becomes a PocketPC-type today application. Karamaba already does this, and on the larger space of the desktop. People have been trying to empty the desktop for years, but to what purpose? Karamba solves that question.
- WinFS, the meta-searching of the file system. It's not actually a filesystem itself, just a search service over the top. Downsides:
-- You need and SQL server always running in memory
-- Your SQL server needs the contents of every file you want to index.
-- You get namespace collisions
-- You're trying to map a heirarchical filesystem to and from a relatonal db.
-- Users don't want to try and Google for their files based on a phrase they think they added to it six months ago. They want to have a folder with an obvious name, and find files beneath that, even the ones they had forgotten.
-- Users don't want to have to deal with adding metadata every time they save a file.
Aside from making the UI a bit more cute and shipping the .NET virtual machine with it, that's Longhorn in a nutshell.
There is nothing there that users actually need. There is nothing there that improves their workflow. Essentially, since windows 95 and office 95, nothing has changed in windows to improve the life of users. USB is the only thing I can think of that has benefitted me, and we all know how unstable windows' USB handling is, especially when hotplugging.
KDE and Linux have now reached a point where they are fully usable on the desktop and are free to innovate further, while windows effectively sits where it is. I think it would be a complete travesty to simply mimic Longhorn, when there are more worthwhile things out there to do. ReiserFS 4, ACLs, tabbed browsing, cards, Umbrello and many others are examples of opensource projects really forging ahead and giving benefits to their users. That is just a taster of a very long list of applications and projects. This is where open source research is at the moment.
Final note; one of the problems we really do have is the assumption that because Apple and MS do something, they've put money and research behind it and it is the right thing to do. On usability, the suggestion that Apple always do what is best for usability is alarming, but it keeps on coming up. Be wary of such assumptions...
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by AC on Wednesday 27/Aug/2003, @03:42
|
I was not referring to a 3D GUI experience here ;) Likely because I am not too good at constructing my thought in English (am dutch using a spell checker) and I am better at coding anyway. I was referring to using the hardware for animated windows themselves, not an interface with 3 axis's. Eye candy and pure usability benefits might breed each other.
_I_ do not expect much exciting new features from Longhorn actually, however the large drones of window users are easily mind bended again and again. We look at it from a much different perspective. Their research capabilities do help them in their favor and I do expect to see some good features from a usability point of view - I could be wrong off coarse!
All I wanted to get at is that having a window as a surface it becomes (new English word I guess) animationable. One can have GUI specialists play with that and come up with innovative features you and I might not expect. That procedure is less likely to happen in the open source environment unless someone develops it in the first place - I think it shows an obstacle for research opportunity, altough my example may be a bad one. I think it applies for several fields in open source.
Your references to all those projects, I was aware of those yes and they are exactly pointing to great open source things happening because of the open source model. What I am getting at is supportive projects for open source projects which I believe can go hand in hand and solve the problem of research I tried bring up.
I'm better at being practical than ranting, so I am going back to work now ;)
AC
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by whatever on Wednesday 27/Aug/2003, @07:36
|
>> All I wanted to get at is that having a window as a surface it becomes (new English word I guess) animationable.
'animatable'.. ;)
And yes, it would definitely make up for some very interesting effects when having the ability to apply xforms to windows or whatever.
I don't think XFree86 will ever be able to do that though.. (not even using cairo)
It's too old for that.
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Nobody on Friday 29/Aug/2003, @04:06
|
So what if it becomes even more clear that X11 cannot handle tomorrow's desktops and there will be real need for OpenGL accellerated windowing system, what then?
Sure you might argue that there is no need right now, and sure that is partially true (well atleast I would love to be able to show off Linux desktop to my Apple and my friends using Apple) but should the Qt4/KDE4 to be designed for the future or for today's hardware and software requirements? I think the only right way for that is to plan to use pure OpenGL as everyone else (like Apple with their Quartz Extreme is doing right now and Longhorn is also going to use it) are and Linux community is going to need to get it done!
So is there any already evaluated windowing systems that might fit the bill? Sure there are some but they are on pretty alpha stage but should there be some chosen system that would surely get more attention in the future?
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Tim Jansen on Friday 29/Aug/2003, @06:17
|
>>So what if it becomes even more clear that X11 cannot handle tomorrow's desktops and there will be real need for OpenGL accellerated windowing system, what then?<<
When did it become clear? X11 does not prevent you at all from using a MacOS X-like, OpenGL based rendering system, at least not at the application level. The apps still render their windows and get their events like they did in the last 20 years. They may use classic X11 functions, new X11 extensions like Cairo graphics or OpenGL over GLX, but they still use rectangular windows as primitives.
The window manager may need to be aware of such a composition system (obviously, current X11 can not transform windows), but not the apps. And even that could be done using a X11 extension, no need to replace X11.
I will never understand why people are so eager to throw away the X11 system, even though they have yet to show a feature that X11 could not do - the only problem are implementations, not the protocol.
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by AC on Saturday 30/Aug/2003, @14:12
|
>>>>I will never understand why people are so eager to throw away the X11 system, even though they have yet to show a feature that X11 could not do - the only problem are implementations, not the protocol
I think this is related to the fact that not everybody understands how X is designed. Most people observe X is almost always causing troubles and causing literal headaches when setting up (refresh rate). Improving its setup procedure might remove most of the bitter experiences people now face with X.
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Tobias Hunger on Monday 01/Sep/2003, @09:43
|
Of course X does not prevent you from doing whatever you want. When you get down to it X is basically a blown up graphics driver. You can pile everything on top of that, you can do all desired effects, etc. Nobody is arguing that point.
But why would you want to? Why are you using languages like C++, Smalltalk or whatnot instead of Assembler? Because you don't want to be bothered with all the bit-pushing that's going on behind the scenes. The same is true with X windows: Who does actually develop for it nowadays? Nobody! All the developers are building their work on toolkits that could be run on any other graphics driver as well (probably better than on X, too:-) or on APIs better suited for their purposes like OpenGL, libArt or some SVG library.
Users don't care about the low level stuff, they still stick with X since all their applications happen to run on that 'driver'. If they switch to something else they are bound to loose some of their favorite applications.
Don't get me wrong: I do use X and I even like it a lot. It is a revolutionary product! But it is time to start to think about what could happen in the past-X(11R6) age. That could be something new like fresco (www.fresco.org) or picogui (www.picogui.org), it will most likely be X as we know it with some more extensions clobbered on or it could be DirectFB/Qt (I'd hate having that, networktransparency rocks) or something completely different!
Anyway, what made me post this is that I hate those "This is great and needs no fixing" attitude. Nothing is perfect, not even X. Why are you so rough to people trying to think out of the box? They could very well come up with some good ideas... which might result in some X successor, however that may look like.
I for one thing have a graphics card that has 10 times the clockspeed of my first PC's CPU. I payed for that power, I want it used. Of course I'd prefer something productive, but I'll settle for eye candy;-) If X can't do that - and as of today it can't - I'm looking for other projects and try to help those along.
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Tim Jansen on Monday 01/Sep/2003, @10:42
|
>>All the developers are building their work on toolkits that could be run on any other graphics driver as well (probably better than on X, too:-) or on APIs better suited for their purposes like OpenGL, libArt or some SVG library.<<
Toolkits are layers on top of X11, and there are good reasons for layering them. The most important ones, probably, are that a) layering increases flexibility and b) the relative simplicity of X11 makes things like NX possible. To use a analogy myself, an approach like Frisco is like improving HTTP by getting rid of TCP and writing an alternative that provides the functionality of HTTP over TCP.
If there is *functionality*, including eye candy, that can not be transported using X11 and its extensions, you could easily convince me that it is a good idea to work on a second protocol. But I don't see it a point as long as the user does not notice any difference except that the old applications don't work anymore. If you start the post-X11 era, you should have a compelling reason for this.
Integrating widgets on the server side in a way that's less flexible than DPS rather limits the capabilities of the window system than increases them. There are still, and always will be, applications that do not want your widget kit and provide their own. Examples are emulators like Wine, and apps that want their own widgets for eye candy reasons (games are the no 1 example, but just look how many Windows apps do not use the Windows widgets).
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Tobias Hunger on Tuesday 02/Sep/2003, @00:45
|
>> Toolkits are layers on top of X11, and there are good reasons for layering them. <<
You are right. My point is that with every application depending on the top layer only, what stops you from even considering switching the bottom layer? That's exactly the increased flexibility you gain by layering! Why are you so much against someone even bringing up the topic?
>> To use a analogy myself, an approach like Frisco is like improving HTTP by getting rid of TCP and writing an alternative that provides the functionality of HTTP over TCP. <<
To stay in the layer-paradigm ou have brought up: Fresco is a set of interfaces defined on top of CORBA which in turn is a protocol defined on top of (among others) TCP/IP. So your analogy should be more like "improving HTTP by replacing it with something more powerful on top of SOAP on top of TCP." with SOAP and TCP being widely adopted standards.
>> If there is *functionality*, including eye candy, that can not be transported using X11 and its extensions, you could easily convince me [...] <<
Device independence, resolution independence, vector-based rendering, 3D capable desktop, and most important of all a consistent look and feel of applications, even while keeping the configurability we all know and love. Just to name a few...
Of course nobody is stopping you from adding all that to X via some extension. We decided not to work on an X extension for a simple reason: All X could do for us is access to the graphics card. We can get that in a more flexible way by using SDL/GGI/DirectFB/GLUT, some of them being able to run inside X or outside. The same is true for input devices. Network/language transparency? We get that for free from using CORBA, a technology necessary to have all the objects communicate (no, we will not replace CORBA, we need all it offers; no, something you need is not bloat; yes, CORBA is slower than sockets but because our architecture is way different from what X does that impacts performance far less then you might think; no, we cannot remove CORBA and replace it with something else). We need to do our own focus- and fonthandling, etc., so why on earth should we limit ourself to being an X extension? Fresco is less then 200K lines of code... why dock that onto a 2M lines of code XFree-monster for that little it offers to us? Right now that would hinder more then it would help.
Anyway: The important issue is that someone is trying out new things in free software and that the code is there. Take the code and turn it into an X extension if you think that's better than what we do. It doesen't matter to me what it is actually called and where it ends up getting used. What matters to me is that someone is experimenting.
>> [...] that it is a good idea to work on a second protocol. <<
We aren't. The protocol is defined by the OMG as part of CORBA and is called IOP. We just provide a set of interfaces on top of this protocol. That's not much different from what KDE and Trolltech do by providing their libraries using the X protocol.
>> If you start the post-X11 era, you should have a compelling reason for this. <<
No, you need a compelling reason not to want to improve on what is already known. The spirit of invention driving human development and all;-)
I am further not starting the post-X era, neither is anyone else in Fresco. We are just trying out some (not that new but still untried) ideas. But then who could claim more for those guys at MIT originally writing X? ;-)
>> Integrating widgets on the server side in a way that's less flexible than DPS rather limits the capabilities of the window system than increases them. <<
Correct. That's why we are not doing it.
>> There are still, and always will be, applications that do not want your widget kit and provide their own. <<
.. which of course they can in Fresco. We just try to discourage that as much as possible, just like Apple, Microsoft and probably KDE, too. And since our concept of a widget, being just some collection of graphics (like everything else on the screen) is way more flexible than the "each widget is a object with hardcoded attributes" used in traditional X toolkits, we are convinced that there is less need for custom widgets.
If you insist on using your own widgets you can, building them up from the same basic building blocks as the 'default' widgets. That is some work of course (not more then inheriting the basic functionality and extending it) and maybe someone will write up a "GUI painter" for that purpose someday... with the GUI consisting of the same elements as a graphics view that will be really easy. Well, there goes the consistency... ;-)
>> Examples are emulators like Wine, and apps that want their own widgets for eye candy reasons <<
The eye-candy reasons does not hold in Fresco:-) If a user wants eye candz he can just replace the admittedly ugly MotifKit with a (to be written) "Fully3DTexturizedMeshesWidgetKit" on his system and he will have eye candy widgets for all his applications. The look and feel can be freely changed by the *user* in Fresco (in X the developer selects the look and feel and might offer some themeability so that the user won't notice this too much;-), all Fresco does is making sure that all applications (that do use the normal interfaces to produce their widgets) look and feel the same.
>> (games are the no 1 example, but just look how many Windows apps do not use the Windows widgets) <<
I do not consider games a no 1 example: They tend to run fullscreen and need all the power the graphics card can deliver, so they usually go around the GUI environment as much as possible. So I don't see much need to discuss games in this context.
Some words about compatibility: You can extend X and you will end up with something else (let's call it Y for now). Anything written for Y won't run on X: backward compatibility is broken. Of course any X application will work on Y, too. That's great and a absolute must have if you ever want to think about replacing X.
But what about writting something (let's call it Fresco here) and implementing a X server in it? Any Fresco application won't work on X, but you could still run X apps on top of Fresco in the embedded X-server. So how does this differ from an extended X from a users point of view? That this is a feastable option was proven by Apple: It is what they have done with there MacOSX GUI.
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Tim Jansen on Tuesday 02/Sep/2003, @09:59
|
> My point is that with every application depending on the top
> layer only, what stops you from even considering switching the bottom
> layer?
There are many top layers that people do not want to miss. Toolkits like Qt, GTK and XUL are very different and the holy grail of widget theming is still to implement a widget style that runs at least on Qt and GTK. So do you want to support only one toolkit, modify at least one of their APIs enough that you can use a single widget implementation or try to write one that is so flexible that it works with both?
And, of course, beside regular toolkits there are other challenges like SDL, apps that use XLib directly for various reasons and statically linked binaries, especially for commercial apps.
> Why are you so much against someone even bringing up the topic?
Sorry, I just heard way too often that dropping X11 solves all problems. And I never saw any proposal (or even code) that solved more problems than it created.
> All X could do for us is access to the graphics card.
It would also offer a communication middleware that is very well known and analyzed, for example regarding performance issues. I don't think that such a amount of research has gone into any CORBA-based rendering system (or maybe even CORBA for applications with real-time characteristics).
> why dock that onto a 2M lines of code XFree-monster for that little it offers
> to us?
While I can understand detesting XFree's (or X.org's) prehistoric code base, it cumulates a lot of experience and code for using graphics hardware on hundreds of different architectures, and is the only widely used X11 implementation. If you want to implement any X11 emulation you would have an hard time to emulate X.org's exact behaviour.
Proprietary drivers for NVidia cards are also a showstopper for everything that does not use XFree's driver model (there is no chance to get people use an OpenGL-based system without NVidia support).
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by wup on Tuesday 02/Sep/2003, @01:37
|
You know what's the whole issue with XFree86?
IT IS TOO OLD AND NOT FLEXIBLE for todays standards (!)
Having said that, see the following comparison:
* setting resolution (@ runtime)
DFB: IDirectFB::SetVideoMode
XFree86: Use XRandr, depth cannot be set
* render an alpha blended rectangle
DFB: IDirectFBSurface::SetDrawingFlags, IDirectFBSurface::FillRectangle
XFree86: Use XRender (or Cairo, which usually uses XRender implicitly)
* getting an OpenGL surface for doing 3D graphics
DFB: IDirectFBSurface::GetGL
XFree86: Use a mix of GLX and X
* double or triple buffering of window surfaces
DFB: Automatic
XFree86: Backing store (b0rked, so not usable)
* documentation
DFB: Nice and easy
XFree86: Boring and hard to read/understand
* system integration
DFB: Boot kernel in graphical mode -> jump right into the desktop (nice!)
XFree86: Boot, mode switch, mode switch, mode switch, ... (ugly & unprofessional looking)
It's just the small things, but as you can see; one very important thing is that DirectFB can do things using a nice API without using yet another library/extension, thanks to the non-dependency on X11.
And not only that, it's also just too easy to create a slow GUI (that is, without Gtk or Qt, though even both these toolkits are still making some mistakes -> see perf docs from KP and that guy @ HP) using XFree86, which is partly the fault of X11 and partly the fault of XFree86 not being improved anymore (for the last few years (!)).
Another issue: the latest standards for eye candy (which is often very usable as well, not just for nice looks (ie. window drop shadows)) are very hard to do using XFree86 (nearly impossible without hacking away).
Using DirectFB it's much easier.. eg. I don't think it would be hard to create genie-like window effects using DFB.
Oh, and writing a driver for DirectFB is also a far more pleasing experience.
It's time for something fresh...
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by anon on Tuesday 02/Sep/2003, @06:39
|
write back when I can use my NV Gf4 at reasonable speeds on DFB
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Tim Jansen on Tuesday 02/Sep/2003, @10:10
|
>IT IS TOO OLD AND NOT FLEXIBLE for todays standards.
Then the easiest solution is to improve it.
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by wup on Tuesday 02/Sep/2003, @11:14
|
>> Then the easiest solution is to improve it.
Probably not, as no person or even group of coders has/have succeeded in doing that the last few years..
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Tim Jansen on Tuesday 02/Sep/2003, @11:24
|
AFAIK no one tried. And by creating something from scratch things won't be easier, because you probably want more features than the 2 millions lines of code in XFree provide, not less.
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Tobias Hunger on Tuesday 09/Sep/2003, @07:56
|
It is easier to create something from scratch!
* You are not stuck to an stone-age (IT industry-wise) protocol
* You do not need to wade through heaps of code added for obsolete architectures
* You do not have to work with a display model that matched the hardware that was available over 10 years ago and needs all kinds of clutches to get adapted to modern 3D accelerator boards and such
* You get a clean set of interfaces instead of the extensions-mess we are seeing in X today with obsolete extensions being dragged through the releases and dozends of interfaces for basically the same functionality.
If throwing out 2 Mio. lines of working code scares you: Don't forget that the 2 Mio. lines of XFree code does include lots of rarely used clients, too which could go with no harm done to get replaced by KDE/Gnome apps providing the same functionality. Then throw out all those obsoleted extensions (only those marked as obsolete and those that never really worked anyway) and you get down to a surprisingly small SLOC count!
The only really interessting thing in XFree are the graphics drivers... and unfortunately those seem to be really hard to rip out due to heavy interdependencies with the rest of the code.
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Bernd Gehrmann on Tuesday 09/Sep/2003, @23:43
|
> You are not stuck to an stone-age (IT industry-wise) protocol
Then I would suggest you to stop using Internet, which is using
a protocol that predates X11 by a decade. Oh, while you are at it,
you may also consider dropping BSD, Linux and other Unix-like
operating systems which are essentially technology of the
late 1960's :-)
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Tobias Hunger on Wednesday 08/Oct/2003, @09:33
|
Networks got faster, sure, but the basic assumption of "shoving data in at one end and getting it out at the other" still holds.
Graphics hardware on the other hand went from "set a couple of its in some chunk of memory" to "Render a Mesh with a lamp setup at this position". With such a change of abstraction level something new might be in order, don't you think?
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Steve Keate on Thursday 15/Jan/2004, @02:30
|
"You know what's the whole issue with XFree86?
IT IS TOO OLD AND NOT FLEXIBLE for todays standards (!)"
This is EXACTLY the argument people use against Unix based OSes, and frankly it's a load of bullshit.
Mac OS X has lineage that can be traced directly back to the original AT&T Unix, historic BSD, and CMU Mach, yet few people would argue that it is not flexible enough for today's standards.
MS Windows is older than X11 (though some of X11's underpinning concepts predate Windows) yet few people would argue that Windows is not flexible enough for today's standards.
The actual limitations inherent in the X11 protocol are fewer than in most contemporary graphics systems since it is conceptually quite abstracted from the hardware, so in fact it's less likely that X11 is going to be fundamentally unsuitable for any type of graphics rendering than, say... Windows.
Mac OS X's Quartz window system uses many of the same ideas for network transparency as well as a fundamentally inefficient PDF based language to represent graphics, yet seems to do quite well for itself in both the performance and flexibility stakes, as evidenced by it's use of eye-candy so rich you want to floss your eyes after watching it for half an hour.
When pointing your finger, you'd do well to remember that there are four more pointing somewhere else.
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by novice_root on Thursday 17/Aug/2006, @03:03
|
I totally agree with you. i just hope some day gnome and kde both will have a choice of running on either of X or DirectFB.
And with intel open sourcing its drivers i hope directfb gets the much needed hardware support.
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Steve Keate on Thursday 15/Jan/2004, @01:22
|
"On usability, the suggestion that Apple always do what is best for usability is alarming, but it keeps on coming up. Be wary of such assumptions..."
I find it ironic that you complain about people claiming that people are constantly raising Apple as a bastion of usability. One only need look at GNOME and KDE's taskbar clones to see obvious evidence that people are in fact looking to Microsoft Windows for their cues for interface design when it comes time to implementation.
People are not suggesting that Apple is a holy grail of usability, but that people should look at other environments rather than simply re-implementing Microsoft's interface because they lack imagination, or in the misguided belief that this makes it easier for people who have already used Windows.
My experience, and something that I recall reading from Sun's usability studies, is that when you clone the appearance of something, they expect that you would clone the behaviour as well. When this is not the case, the experience is very jarring and irritating.
Imagine getting into a car, and finding that the pedals are used to steer, and the steering wheel does not move side to side, but back and forth to control acceleration, and you have some idea of why this is.
I would prefer to see a user interface that isn't a clone of Classic MacOS, OS X or Windows, and is in fact a rethink of all that we have come to hold dear in computing, if the end result is better than what we have now.
I hold up Slicker and Enlightenment as examples of this kind of thing. You don't always win, but you also don't learn without making mistakes, and you don't innovate by copying.
Which I think brings us to the point you were trying to make. :)
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Blah on Monday 01/Sep/2003, @09:05
|
Allot = a lot. Get it right, you product-of-society fucktard.
|
[
Reply To This | View ]
|
Re: Qt on DirectFB
by Alex on Tuesday 02/Sep/2003, @09:52
|
hahahahahahahaha
please rot :)
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
