Th erender extension is just that: an extension to X.
X + Extension != X
X11R6 was defined 1996 IIRC. There is nothing about an render extension in there. So you can have a X11R6 display server that can't run Gnome. Is that what you are saying? Is it possible to run GTK+ apps on vanilla X servers?
Re:lets "debunk" those first screen shot aguments.
on
Has GNOME Become LAME?
·
· Score: 1
It's allways the same and I'm getting so tiered of this:
Apple invents something. OSS/free software community ignores it.
Microsoft reinvents the same thing (usually poorly) a couple of years later. OSS/free software community claims that it kills productivity, that it is bloat or insecure. If nobody finds some good argument then it is claimed to be eye-candy only and "Some of us don't need it sugar coated." Anyone claiming otherwise is called names like "wank gnu newbee or a closet case ms lover" to quote some of the better:-)
About one year later somebody hacks something similar together (be it a new windowmanager, X Extension, network tool, application, whatever), and suddenly everybody agrees that it is the best thing since sliced bread and way better then everything that was ever available
We had that with desktop environmants (the command line is so much better!). Yes, it is for those of us that remember all the commandline options from all programs they've ever used. I for one prefer the CLI for everything I do regulary and a GUI for all the stuff I do so rarely that I keep forgetting the details on how to do it in CLI-mode. And yes, Linux only has poor reimplementations of Apple's ideas as far as desktop environmants are concerned.
Then there were transparent windows ("eye candy" turned into "looks so cool").
Next will be rendevous (zero administration network configuration) and vector based GUIs (just look at all the hype about some really simple SVG lib we recently had here on/.).
What is the "artist" you are speaking about? Somebody creating art on a computer? A musician or graphic artist? Don't those usually prefer Apples, a system that is consistent more then any other? Those poeple want to concentrate on their work, not on their tool (the computer), I doubt that many will choose Linux (independent of wether it's running KDE or Gnome).
Your picture do not hold up either. Consistency is not about the number of colours that cited artist uses. It is about all brushes working the same way. What we have on Linux is one brush only working on mondays, one that can only be used to paint strokes from top to bottom and some brushes that break as soon as the artist touches them. I doubt any visual artist would want to use those tools! A musician might play many different instruments, but he expects all of them to behave consistently: To give the note he requests of them. A actor will expect his makeup to work for any role he is playing too (if he decides to need that particular piece of makeup to flesh out the character he is going to impersonate).
You are mistaking the computer to be the piece of art that gets created, not as the tool it is, helping to create art. Even those people programming as a hobby tend to not think that way about the complete system: They might think of themsleves as artists, working on a particularily beautiful piece of code. But so far I never meet anyone who included all the tools used to work on that code (compiler, editors, kernel, GUI system, etc.) to be part of the creation process.
Please read the docs on SOAP. It is a SIMPLE Object Activation Protocol. CORBA is not that simple, but then it has way more features. It's the usual balance between having one System that can do much and anotherone that does much less. Guess which one usually is more simple to use. And please don't judge CORBA by it's C bindings... OO in C is really ugly to start with, adding location transparency does not really help to make it more beautiful.
Your points are not true either, please read the CORBA specs before making such false claims.
And finally I want to mention an additional advantage of CORBA: It does *NOT* use port 80 and does *NOT* tunnel through all kinds of firewalls easily. Firewalls are build to stop people from doing stupid things, they are a good thing. If you need to access something through your firewall and you are not allowed to, go and ask your system administrator. He ususally has some very good reasons for what he is doing and will open the ports you need if there are no reasons not to.
Just because vector-based GUIs were no good 25 years ago does not mean they will suck now. In fact I'm convinced moving from pixel-based to vector-based is a necessary step that will need to happen in the free software world soon. The mayor commercial companies either have allready taken this step (Apple) or are preparing to do so in the next release of their environment (Microsoft).
During the last 25 years there were only rather simple graphic cards. Today, with people putting 500MHz, 128MiB graphic boards (that's more graphic memory then my first PC's harddisc had and 20x the clock speed!) into their computers, staying in the pixelworld is just a terrible waste of resources. There's not too much you can do to speed up pixel-based rendering, most that could be done was allready handled by those "Window accelerator boards" in fashion a couple of years back.
Having said this I don't consider those historic vector-based systems a failure either: Most are much more thought out then their more hackish pixel-based counterparts that were on the market at the same time. Technology had not stopped them, they were killed mostly by other decisions: NeXT introduced a new language for their system for example, stopping many developers from contributiong (at least till they had learned the ObjectiveC extensions to the vanilla C). Then hardly any of those environments was cross-plattform, so there was little incentitive for companies to write software for those systems. Finally there was no free implementation so there wasen't much free software written.
PS: I really find the inovation cycle in free software so depressiong:
Apple turns a great idea that has been around for a while into a product.
The (free software|open source) community ignores it.
Microsoft copies the idea from Apple
The community argues that the whole thing is eye-candy und ruins productivity
Some wierdo hacks together yet another extension to X (be it a 'real extension', a windowmanager or whatever), bringing that feature in some limited but cool looking way to the community.
The community claims the new feature is god-send and makes Linux ready for the desktop.
Some other project decides to write a free replacement of the Microsoft-tool which at some point becomes useful and maybe even better then the original.
Everybody (in the community) agrees that the free software model is so much better because it was able to copy the original thing in hardly no time doing minor improvements along the way.
That's so sad:-(This happened with things like graphical configuration tools and filemanagers to name just two, it will happen with vector-based GUI environments. We should be able to do better then this! Sorry, I'm a bit depressed today... please excuse my negative tendencies:-|
Well, it does not surprise me... having a own domain is cool, I know. But john.doe.name just sounds stupid. And the more common names should be taken allready anyway. How they they handle that? john.smith294.name? Definitly uncool:-(
The registrar claims it is for indivuduals to register their name. I just tried "www.john.smith.name" und ended at www.smith.com, some company website. Doesen't that spoil the purpose?
Finally the website of that registrar claims that john smith "may be available right now." It's not, or it wouldn't redirect me to that company website. Why doesen't the registrar say so? What good is that query field if it cannot even figure out names that even my DNS server knows to be taken?
Now instead of this ridiculous ".name" they should have introduced ".sex" and forced all those sex-companies into that TLD. That could have helped parents to make sure their children do not get exposed to lots of the smut on the net and I'd be happy with just blocking all mails from "*.sex" and have way less spam in my inbox. Of course that wouldn't have worked out completly -- someone is bound to try to offer adult content under other TLDs -- but I'm sure it would have helped.
Re:Apples and oranges
on
.NET or CORBA?
·
· Score: 2, Informative
CORBA has a lot of services too. There's a security service, nameservice and lots of others. Persistent object storage and transactions are among them, too.
The downside is that not all ORBs do offer all services. That's better with J2EE and.Net: You got only one vendor with both, so their products are allways complete. The implementation is the definition of the standard after all:-)
Re:Python is distributed?
on
.NET or CORBA?
·
· Score: 2, Interesting
Python got CORBA bindings and those are great! CORBA with C sucks, CORBA with C++ is nice, CORBA with Python rocks.
Regards, Tobias
What's got OpenGL got to do with CORBA?
on
.NET or CORBA?
·
· Score: 5, Insightful
CORBA is a architecture that allows objects -- implemented in different languages and running distributed over a network consisting of mashines of different architectures -- to communicate. I fail to see how GTK or OpenGL get into the picture here...Of course you can use OpenGL, GTK or any other library in your CORBA objects (if you implement them in a language matching the library you want to use), but that got absolutely nothing to do with CORBA per se. CORBA's location transparency makes using such libraries a bit harder of course: You need to make sure all relevant objects are on the same mashine for one thing. Then you might end up with a multithreaded application because of the CORBA ORB you have choosen which might confuse some of the libraries you want to use.
Having said this it is hard to give any advice based on the little information you provide. CORBA is a very powerful architecture, deffinitly more powerful then SOAP (No object-by-refernce or activation for example) and others. As allmost allways this power comes at the price of complexity. You'll need to sit down, figure out your requirements for the communications architecture you need and then go over the list of available alternatives.
I can't really say much about.Net, having not used it yet. But in general I'd prefer to base my work on a architecture that has had some years to settle. And.Net is so far rather restricted to one plattform. Mono might change that in time, but with its head developer announcing that they'll just drop whichever part might get them into legal trouble I wouldn't want to base my company's products on that plattform. You might wake up one morning and find out that that mono suddenly no longer supports networking or something;-)
I guess the gcc-people are not really good designers then wrt. C++. Try this: Write a hello world in C++, include just one STL-header, run g++ -E and run a linecount on the output: Your few lines of code turned into well over 30000 lines that g++ sees and works on! So precompiled headers should make things faster, even if your own code is well structured.
Re:is this supposed to be useful? amp
on
Fresco M1 Released
·
· Score: 2
Very simple reason: When you use a graphic program, then you do expect to be able to rotate graphics, don't you? So we had to program rotateble graphics. No way around that. In fact we'd have to write some code to stop people from being able to rotate windows! What a waste of time;-)
A Window is a graphic in Fresco. So you can rotate them. Nobody really played with such an idea yet, so I don't know wether it improves useability or not. Somebody suggested to move 'dangerous' operations like 'close window' etc. onto the backside of a window and display some information there (PID, a CPU usage graph, things like that). With Fresco you got the chance to try that...
Finally in a 3D walkin environement you need to be able to display windows in all kinds of ways as you can walk around them. Fresco is capable of running in such an environment (in theory, ran once in a CAVE IIRC but crashed due to buggy libraries;-).
1. Why not? I'll tell you why not, the average open source desktop is rough and burred around the edges, it is immature and majorly buggy. X is a small part of the desktop that is not quite as bad as gnome, kde etc. as it is older and therefore more refined. Fresco is unpolished and raw. That is exactly what we don't want. And we don't want to recode every single graphical app either.
I don't consider Fresco to be raw around the edges. The ideas were around for a long time now, the architecture is definitly more refined then any other windowing-system's I've seen so far. And I looked into a lot, both before I started to work on Fresco and after.
[...]They concede that X has real-world measurment support and make the feeble claim that it is simply being ignored. Instead they simply beleive that in their project measurements will not be ignored although in all probibility people will still use pixels and bitmaps and all the other evil unscalable nasty things. To me this assumption of theirs seems completly unfounded. The X compatibility will be discussed later.
Very simple: There are no pixels in Fresco. You can of course display a image, but only if you specify a resolution for it. It will be scaled to have the right size on the monitor.
The compatibility issue is discussed in detail in out FAQ which I am sure you have read. Too lazy to duplicate it here. I further don't feel like discussing your idea of choice being bad.
We don't consider games. Those usually run fullscreen, so why should they bother to use Fresco in the first place? Any windowing system is unneeded overhead for things like that.
CAD and 3D modeller are up another alley:-) Such applications usually manage a scenegraph describing the objects and their relations to each other. That maps wonderfully to Fresco: That uses a scenegraph too. So far we have only very simple demos showing very simple meshes. We could need some help polishing this of a bit.
Performance should be similar to X or window's performance of those applications inside their window. The difference is of course, that with fresco 3D is 'liberated from simple 2D windows'.
This should work over the network. All objects are stored inside the server, so only very little information needs to go over the wire once the object is set up. The server can use whichever graphic acceleration build into the hardware it runs on, independent of wether the client runs locally or connects over the network.
There's a list of GUI-related projects I find very inspiring on Fresco's link page under Other GUI Projetcs. I hope we can get all the good things from all those systems together into Fresco... of course since they vary widely wrt. the scope and ideas behind each project that will not really be possible. But all of them have some very nice ideas and deserve to get some attention from anyone wanting to design a new GUI system (or improve an existing one) IMHO.
Also make sure to check out the "Important external Link" Sections for such interessting things like Squeak and more:-)
Do you have a link to more informations on NeWS (or other projects as interessting as that)? The one in said list does not really give that much information...
We are looking into gstreamer, MAS (multimediaapplicationserver.org iirc) and other projects. No concreate plans are made (yet) Anyone interessted in sound on fresco?;-)
I just read your abstract. I find it a bit limiting. For example I do not see the need to restrict a windowing system to (one) keyboard and (one) mouse. Of course you can field useability concerns (more then one keyboard/mouse cannot get used at any one time, so it's a unnecessary), but what about graphic tablets, data gloves, etc? Those should be useable with a system designed today.
Gesture handling is of some concern to us. I personally prefer the BeOS-way to handle and preprocess events here to what you propose though.
I have myself not spend much time on thinking about clippbords and such. So I cannot aomment on that part of your abstract. Feel free to discuss it on our ML if you like:-)
Replace users with develeopers and I can agree with you to some degree Fresco is way different from X, so developers will need to rethink their practices if they want to use Fresco. That's somethiong of a big concern to me, but 'bending' the architecture to be more in sync with 'traditional' GUI environments so developers will feel more comftable does not feel right. I do hope that we might be able to hide some of the differences behind some client-side library... but even then rethinking will be necessary for developers. I doubt that users will have such problems.
To realize a GTK/QT you'd do a clientside library. So you can have a rather close bound between client and library. They won't use CORBA to communicate, just like those Toolkits in X don't. So I fail to see your point.
A X on top of berlin will of course need to use the X-protocol. So how does CORBA get into this picture?
In principle every graphic can be zoomed. Lines, 3D Objects, windows, buttons, pictures (for example icons) even the whole desktop is a graphic. Does that answer your question?;-)
Internally fresco uses a device independent format to store all graphics. The internal fromat is rather powerful, featuring complex object (complete meshes and such).
This device independent graphics is passed to a 'DrawingKit' when it needs to get displayed. This DrawingKit turns the internal representation into something the hardware can understand. So far that's plain pixels, Postscript or OpenGL. With plain pixels there's not much to accelerate... But using OpenGL speeds things up tremendously: All the DrawingKit has to do is accept a mesh, hand it over to OepnGL. That will use whichever acceleration your card offers...
The speedup is significant. On my lowly GeForce2 Go it's about 15 times faster then plain software rendering.
A animated gif is just a picture, isen't it? Why should your clients state change? Of course it would need to change if you'd need to syncronize somehting with the gif's update cycle, but for a ad in a webpage that's usually not necessary. So: Usually no communication needed.
Text is a somewhat more complicated matter: Text changes need to be communicated back to the client. So there's a roundtrip hidden here. That's not as bad as it might sound: The server needs to cache the text anyway (needing to store all information needed to redraw and all), so usually you will do a 'block-transfer' at some point (aka. all changes in lines 20 to 30).
CORBA could be faster I guess. For one thing it encodes everything it sends out over the wire as text messages... nice to debug but not really mashine friendly. Then CORBA does a lot more then simply passing a message. It handles all those nasty details you have to keep an eye on in a distributed, heterogenious world. It would definitly be a lot simpler if it could just assume all mashines to have the same character encoding, endianess,... like Cplant obviously can.
Fortunately CORBA can leave out a lot of the overhead in the 'local case' when communicationg with objects on the same mashine or even in the same address space.
You are right: We need to do roundtrips for the few calls we need to make. Fortunately Fresco is designed not to need much kommunication in the first place: We are not poshing pixels around. The Display server has all the information needed to rerender the (transformed) GUI of any application running at that server. The only calls between client and server happens when the server informs the client about a statechange.
The demo application uses a bandwith of about 1.9kBit/s... That's because the server pings the clients to check wether they are stoll alive.
Some comments on other comments that are bound to pop up:
*) Yes Fresco uses CORBA and it is a good thing. It gives network transparency and language transparency for free. Yes, we know it is slower then using raw sockets, but CORBA is the only thing available powerful enough for our needs. It's not bloat if you need the features;-)
*) Fresco is not X: Yes, we do not extend X. X is good, we do think so too, but it has certain shortcommings we do want to adress. Improving X is not an option: We'd need to carry along tons of code we do not need and blow the code size out of proportion (example: xlib, networking code).
*) Fresco is not x compatible now. Support for that can and will be added later. Options for that are manigfold, See our FAQ for more infos on this topic. Again: we do not see that extending X is a good idea: Extending X will result in apps using that extension not being able to run on the unextended X. Fresco apps don't do so either. Both, an extended X and a Fresco with compatibility layer can run X apps. NO, there is no compatibility layer yet.
*) We do not write drivers. We can use whichever drivers are supported by our rendering backends. That's a surprising lot. You can run Fresco in a window in X, using your XFree-driver too.
*) Fresco is device independent. So changing the screen resolution will not make windows smaller and you can print everything you can display on screen. That's a good thing (if you want your windows to become smaller you adjust their zoom factor).
*) No, Fresco is not about rotating windows. We can rotate windows, we do so in our screenshots. That's basically because making windows not rotateable would require us to write code to prevent it! And it's an eye catcher.
*) No, this is in no way ready for the end user. Developers are welcome.
That's the basic things I want to get straight early on. From earlier/. experiences I know that these misunderstandingfs/questions are bound to crop up.
Yes, one of the last items we need to do before having a new release of Fresco is to explain why we changed the projects name from Berlin to Fresco.
Berlin started out as one of those who-needs-network-transparency-anyway projects. The goals have changed a lot since then, incorporationg all the ideas from what we now call 'vintage' Fresco: A Toolkit for X whos ideas are now the foundation of our work. To reflect that (and since we were able to get fresco.org;-) we decided to rename the project. It will be officially announced once the new release gets out.
Basically the project and the protocol (better: The IDL interfaces) are renamed to Fresco. Our implementation of said interfaces keeps the name Berlin. So Fresco is to Berlin what X is to XFree86.
Of course we do have 'bindings' for other languages besides python and C++ too. Java and Perl have both been used allready and in principle you can use any language with a CORBA ORB right out of the box. Since the widgets are realized inside the server and written in C++ your scripts will not feel sluggish:-)
Yes, transparency is nice, but we do get that basically for free from our architecture. The same is true about being able to rotate windows. I'm bringing this up since many people think we spend our time with eye-candy like that, but in fact we'd need to write lots of code to stop people from being able to rotate windows! That's why we let them (and because rotated windows allways draw attention to our screenscots;-)
But the thing I love the most about fresco is device independance: You give sizes in real word units and have them displayed correctly on your monitor independent of its resolution. You just rerender windows (or parts thereof) once using a so called DrawingKit generating Postscript instead of OpenGL or raster images (both can be used to display on your screen, depending on your graphics card) and have a screenshot.
Regards, Tobias
PS: Yes, Fresco used to be a Toolkit for X. Yes we could do the same and 'fill in the gaps of X', but we do not feel that's worthwhile: We'd need to meddle with lots of code we don't really need to be concerned with (basically all of X;-), we'd add lots of code ourselves since we'd need to duplicate much of the existing code (network layer, device handling, etc.) with libraries we use or our own code. So concerning ourselves with X would slow us down even more then our permanent developer's shortage;-) And I am still convinced that writting a clean display server and then integrating a X compatibility layer ontop of it (like Apple did for example) is the better way to go then to lump even more extensions and toolkits ontop of X. We definitly have enough of those to be a real pita!
Slashdot Mirror
Th erender extension is just that: an extension to X.
X + Extension != X
X11R6 was defined 1996 IIRC. There is nothing about an render extension in there. So you can have a X11R6 display server that can't run Gnome. Is that what you are saying? Is it possible to run GTK+ apps on vanilla X servers?
It's allways the same and I'm getting so tiered of this:
/.).
Apple invents something. OSS/free software community ignores it.
Microsoft reinvents the same thing (usually poorly) a couple of years later. OSS/free software community claims that it kills productivity, that it is bloat or insecure. If nobody finds some good argument then it is claimed to be eye-candy only and "Some of us don't need it sugar coated." Anyone claiming otherwise is called names like "wank gnu newbee or a closet case ms lover" to quote some of the better:-)
About one year later somebody hacks something similar together (be it a new windowmanager, X Extension, network tool, application, whatever), and suddenly everybody agrees that it is the best thing since sliced bread and way better then everything that was ever available
We had that with desktop environmants (the command line is so much better!). Yes, it is for those of us that remember all the commandline options from all programs they've ever used. I for one prefer the CLI for everything I do regulary and a GUI for all the stuff I do so rarely that I keep forgetting the details on how to do it in CLI-mode. And yes, Linux only has poor reimplementations of Apple's ideas as far as desktop environmants are concerned.
Then there were transparent windows ("eye candy" turned into "looks so cool").
Next will be rendevous (zero administration network configuration) and vector based GUIs (just look at all the hype about some really simple SVG lib we recently had here on
Wow... a creative spirit speaks up for Gnome.
What is the "artist" you are speaking about? Somebody creating art on a computer? A musician or graphic artist? Don't those usually prefer Apples, a system that is consistent more then any other? Those poeple want to concentrate on their work, not on their tool (the computer), I doubt that many will choose Linux (independent of wether it's running KDE or Gnome).
Your picture do not hold up either. Consistency is not about the number of colours that cited artist uses. It is about all brushes working the same way. What we have on Linux is one brush only working on mondays, one that can only be used to paint strokes from top to bottom and some brushes that break as soon as the artist touches them. I doubt any visual artist would want to use those tools! A musician might play many different instruments, but he expects all of them to behave consistently: To give the note he requests of them. A actor will expect his makeup to work for any role he is playing too (if he decides to need that particular piece of makeup to flesh out the character he is going to impersonate).
You are mistaking the computer to be the piece of art that gets created, not as the tool it is, helping to create art. Even those people programming as a hobby tend to not think that way about the complete system: They might think of themsleves as artists, working on a particularily beautiful piece of code. But so far I never meet anyone who included all the tools used to work on that code (compiler, editors, kernel, GUI system, etc.) to be part of the creation process.
Please read the docs on SOAP. It is a SIMPLE Object Activation Protocol. CORBA is not that simple, but then it has way more features. It's the usual balance between having one System that can do much and anotherone that does much less. Guess which one usually is more simple to use. And please don't judge CORBA by it's C bindings... OO in C is really ugly to start with, adding location transparency does not really help to make it more beautiful.
Your points are not true either, please read the CORBA specs before making such false claims.
And finally I want to mention an additional advantage of CORBA: It does *NOT* use port 80 and does *NOT* tunnel through all kinds of firewalls easily. Firewalls are build to stop people from doing stupid things, they are a good thing. If you need to access something through your firewall and you are not allowed to, go and ask your system administrator. He ususally has some very good reasons for what he is doing and will open the ports you need if there are no reasons not to.
During the last 25 years there were only rather simple graphic cards. Today, with people putting 500MHz, 128MiB graphic boards (that's more graphic memory then my first PC's harddisc had and 20x the clock speed!) into their computers, staying in the pixelworld is just a terrible waste of resources. There's not too much you can do to speed up pixel-based rendering, most that could be done was allready handled by those "Window accelerator boards" in fashion a couple of years back.
Having said this I don't consider those historic vector-based systems a failure either: Most are much more thought out then their more hackish pixel-based counterparts that were on the market at the same time. Technology had not stopped them, they were killed mostly by other decisions: NeXT introduced a new language for their system for example, stopping many developers from contributiong (at least till they had learned the ObjectiveC extensions to the vanilla C). Then hardly any of those environments was cross-plattform, so there was little incentitive for companies to write software for those systems. Finally there was no free implementation so there wasen't much free software written.
PS: I really find the inovation cycle in free software so depressiong:
Apple turns a great idea that has been around for a while into a product.
The (free software|open source) community ignores it.
Microsoft copies the idea from Apple
The community argues that the whole thing is eye-candy und ruins productivity
Some wierdo hacks together yet another extension to X (be it a 'real extension', a windowmanager or whatever), bringing that feature in some limited but cool looking way to the community.
The community claims the new feature is god-send and makes Linux ready for the desktop.
Some other project decides to write a free replacement of the Microsoft-tool which at some point becomes useful and maybe even better then the original.
Everybody (in the community) agrees that the free software model is so much better because it was able to copy the original thing in hardly no time doing minor improvements along the way.
:-(This happened with things like graphical configuration tools and filemanagers to name just two, it will happen with vector-based GUI environments. We should be able to do better then this! Sorry, I'm a bit depressed today... please excuse my negative tendencies:-|
That's so sad
Well, it does not surprise me... having a own domain is cool, I know. But john.doe.name just sounds stupid. And the more common names should be taken allready anyway. How they they handle that? john.smith294.name? Definitly uncool:-(
The registrar claims it is for indivuduals to register their name. I just tried "www.john.smith.name" und ended at www.smith.com, some company website. Doesen't that spoil the purpose?
Finally the website of that registrar claims that john smith "may be available right now." It's not, or it wouldn't redirect me to that company website. Why doesen't the registrar say so? What good is that query field if it cannot even figure out names that even my DNS server knows to be taken?
Now instead of this ridiculous ".name" they should have introduced ".sex" and forced all those sex-companies into that TLD. That could have helped parents to make sure their children do not get exposed to lots of the smut on the net and I'd be happy with just blocking all mails from "*.sex" and have way less spam in my inbox. Of course that wouldn't have worked out completly -- someone is bound to try to offer adult content under other TLDs -- but I'm sure it would have helped.
CORBA has a lot of services too. There's a security service, nameservice and lots of others. Persistent object storage and transactions are among them, too.
.Net: You got only one vendor with both, so their products are allways complete. The implementation is the definition of the standard after all:-)
The downside is that not all ORBs do offer all services. That's better with J2EE and
Python got CORBA bindings and those are great! CORBA with C sucks, CORBA with C++ is nice, CORBA with Python rocks.
Regards, Tobias
CORBA is a architecture that allows objects -- implemented in different languages and running distributed over a network consisting of mashines of different architectures -- to communicate. I fail to see how GTK or OpenGL get into the picture here. ..Of course you can use OpenGL, GTK or any other library in your CORBA objects (if you implement them in a language matching the library you want to use), but that got absolutely nothing to do with CORBA per se. CORBA's location transparency makes using such libraries a bit harder of course: You need to make sure all relevant objects are on the same mashine for one thing. Then you might end up with a multithreaded application because of the CORBA ORB you have choosen which might confuse some of the libraries you want to use.
.Net, having not used it yet. But in general I'd prefer to base my work on a architecture that has had some years to settle. And .Net is so far rather restricted to one plattform. Mono might change that in time, but with its head developer announcing that they'll just drop whichever part might get them into legal trouble I wouldn't want to base my company's products on that plattform. You might wake up one morning and find out that that mono suddenly no longer supports networking or something;-)
Having said this it is hard to give any advice based on the little information you provide. CORBA is a very powerful architecture, deffinitly more powerful then SOAP (No object-by-refernce or activation for example) and others. As allmost allways this power comes at the price of complexity. You'll need to sit down, figure out your requirements for the communications architecture you need and then go over the list of available alternatives.
I can't really say much about
Regards, Tobias
I guess the gcc-people are not really good designers then wrt. C++. Try this: Write a hello world in C++, include just one STL-header, run g++ -E and run a linecount on the output: Your few lines of code turned into well over 30000 lines that g++ sees and works on! So precompiled headers should make things faster, even if your own code is well structured.
Very simple reason: When you use a graphic program, then you do expect to be able to rotate graphics, don't you? So we had to program rotateble graphics. No way around that. In fact we'd have to write some code to stop people from being able to rotate windows! What a waste of time;-)
A Window is a graphic in Fresco. So you can rotate them. Nobody really played with such an idea yet, so I don't know wether it improves useability or not. Somebody suggested to move 'dangerous' operations like 'close window' etc. onto the backside of a window and display some information there (PID, a CPU usage graph, things like that). With Fresco you got the chance to try that...
Finally in a 3D walkin environement you need to be able to display windows in all kinds of ways as you can walk around them. Fresco is capable of running in such an environment (in theory, ran once in a CAVE IIRC but crashed due to buggy libraries;-).
I don't consider Fresco to be raw around the edges. The ideas were around for a long time now, the architecture is definitly more refined then any other windowing-system's I've seen so far. And I looked into a lot, both before I started to work on Fresco and after.
Very simple: There are no pixels in Fresco. You can of course display a image, but only if you specify a resolution for it. It will be scaled to have the right size on the monitor.
The compatibility issue is discussed in detail in out FAQ which I am sure you have read. Too lazy to duplicate it here. I further don't feel like discussing your idea of choice being bad.
You are very welcome to do so. I just hope you do use WM in a amiga-ish kind of way and don't think Fresco is a WindowManager;-)
We don't consider games. Those usually run fullscreen, so why should they bother to use Fresco in the first place? Any windowing system is unneeded overhead for things like that.
CAD and 3D modeller are up another alley:-) Such applications usually manage a scenegraph describing the objects and their relations to each other. That maps wonderfully to Fresco: That uses a scenegraph too. So far we have only very simple demos showing very simple meshes. We could need some help polishing this of a bit.
Performance should be similar to X or window's performance of those applications inside their window. The difference is of course, that with fresco 3D is 'liberated from simple 2D windows'.
This should work over the network. All objects are stored inside the server, so only very little information needs to go over the wire once the object is set up. The server can use whichever graphic acceleration build into the hardware it runs on, independent of wether the client runs locally or connects over the network.
There's a list of GUI-related projects I find very inspiring on Fresco's link page under Other GUI Projetcs. I hope we can get all the good things from all those systems together into Fresco... of course since they vary widely wrt. the scope and ideas behind each project that will not really be possible. But all of them have some very nice ideas and deserve to get some attention from anyone wanting to design a new GUI system (or improve an existing one) IMHO.
Also make sure to check out the "Important external Link" Sections for such interessting things like Squeak and more:-)
Do you have a link to more informations on NeWS (or other projects as interessting as that)? The one in said list does not really give that much information...
We are looking into gstreamer, MAS (multimediaapplicationserver.org iirc) and other projects. No concreate plans are made (yet) Anyone interessted in sound on fresco? ;-)
Not really:-)
I just read your abstract. I find it a bit limiting. For example I do not see the need to restrict a windowing system to (one) keyboard and (one) mouse. Of course you can field useability concerns (more then one keyboard/mouse cannot get used at any one time, so it's a unnecessary), but what about graphic tablets, data gloves, etc? Those should be useable with a system designed today.
Gesture handling is of some concern to us. I personally prefer the BeOS-way to handle and preprocess events here to what you propose though.
I have myself not spend much time on thinking about clippbords and such. So I cannot aomment on that part of your abstract. Feel free to discuss it on our ML if you like:-)
Replace users with develeopers and I can agree with you to some degree Fresco is way different from X, so developers will need to rethink their practices if they want to use Fresco. That's somethiong of a big concern to me, but 'bending' the architecture to be more in sync with 'traditional' GUI environments so developers will feel more comftable does not feel right. I do hope that we might be able to hide some of the differences behind some client-side library... but even then rethinking will be necessary for developers. I doubt that users will have such problems.
To realize a GTK/QT you'd do a clientside library. So you can have a rather close bound between client and library. They won't use CORBA to communicate, just like those Toolkits in X don't. So I fail to see your point.
A X on top of berlin will of course need to use the X-protocol. So how does CORBA get into this picture?
In principle every graphic can be zoomed. Lines, 3D Objects, windows, buttons, pictures (for example icons) even the whole desktop is a graphic. Does that answer your question? ;-)
Internally fresco uses a device independent format to store all graphics. The internal fromat is rather powerful, featuring complex object (complete meshes and such).
This device independent graphics is passed to a 'DrawingKit' when it needs to get displayed. This DrawingKit turns the internal representation into something the hardware can understand. So far that's plain pixels, Postscript or OpenGL. With plain pixels there's not much to accelerate... But using OpenGL speeds things up tremendously: All the DrawingKit has to do is accept a mesh, hand it over to OepnGL. That will use whichever acceleration your card offers...
The speedup is significant. On my lowly GeForce2 Go it's about 15 times faster then plain software rendering.
A animated gif is just a picture, isen't it? Why should your clients state change? Of course it would need to change if you'd need to syncronize somehting with the gif's update cycle, but for a ad in a webpage that's usually not necessary. So: Usually no communication needed.
Text is a somewhat more complicated matter: Text changes need to be communicated back to the client. So there's a roundtrip hidden here. That's not as bad as it might sound: The server needs to cache the text anyway (needing to store all information needed to redraw and all), so usually you will do a 'block-transfer' at some point (aka. all changes in lines 20 to 30).
Regards,
Tobias
CORBA could be faster I guess. For one thing it encodes everything it sends out over the wire as text messages... nice to debug but not really mashine friendly. Then CORBA does a lot more then simply passing a message. It handles all those nasty details you have to keep an eye on in a distributed, heterogenious world. It would definitly be a lot simpler if it could just assume all mashines to have the same character encoding, endianess, ... like Cplant obviously can.
Fortunately CORBA can leave out a lot of the overhead in the 'local case' when communicationg with objects on the same mashine or even in the same address space.
You are right: We need to do roundtrips for the few calls we need to make. Fortunately Fresco is designed not to need much kommunication in the first place: We are not poshing pixels around. The Display server has all the information needed to rerender the (transformed) GUI of any application running at that server. The only calls between client and server happens when the server informs the client about a statechange.
The demo application uses a bandwith of about 1.9kBit/s... That's because the server pings the clients to check wether they are stoll alive.
Some comments on other comments that are bound to pop up:
/. experiences I know that these misunderstandingfs/questions are bound to crop up.
*) Yes Fresco uses CORBA and it is a good thing. It gives network transparency and language transparency for free. Yes, we know it is slower then using raw sockets, but CORBA is the only thing available powerful enough for our needs. It's not bloat if you need the features;-)
*) Fresco is not X: Yes, we do not extend X. X is good, we do think so too, but it has certain shortcommings we do want to adress. Improving X is not an option: We'd need to carry along tons of code we do not need and blow the code size out of proportion (example: xlib, networking code).
*) Fresco is not x compatible now. Support for that can and will be added later. Options for that are manigfold, See our FAQ for more infos on this topic. Again: we do not see that extending X is a good idea: Extending X will result in apps using that extension not being able to run on the unextended X. Fresco apps don't do so either. Both, an extended X and a Fresco with compatibility layer can run X apps. NO, there is no compatibility layer yet.
*) We do not write drivers. We can use whichever drivers are supported by our rendering backends. That's a surprising lot. You can run Fresco in a window in X, using your XFree-driver too.
*) Fresco is device independent. So changing the screen resolution will not make windows smaller and you can print everything you can display on screen. That's a good thing (if you want your windows to become smaller you adjust their zoom factor).
*) No, Fresco is not about rotating windows. We can rotate windows, we do so in our screenshots. That's basically because making windows not rotateable would require us to write code to prevent it! And it's an eye catcher.
*) No, this is in no way ready for the end user. Developers are welcome.
That's the basic things I want to get straight early on. From earlier
Regards,
Tobias
Berlin started out as one of those who-needs-network-transparency-anyway projects. The goals have changed a lot since then, incorporationg all the ideas from what we now call 'vintage' Fresco: A Toolkit for X whos ideas are now the foundation of our work. To reflect that (and since we were able to get fresco.org;-) we decided to rename the project. It will be officially announced once the new release gets out.
Basically the project and the protocol (better: The IDL interfaces) are renamed to Fresco. Our implementation of said interfaces keeps the name Berlin. So Fresco is to Berlin what X is to XFree86.
Of course we do have 'bindings' for other languages besides python and C++ too. Java and Perl have both been used allready and in principle you can use any language with a CORBA ORB right out of the box. Since the widgets are realized inside the server and written in C++ your scripts will not feel sluggish:-)
Yes, transparency is nice, but we do get that basically for free from our architecture. The same is true about being able to rotate windows. I'm bringing this up since many people think we spend our time with eye-candy like that, but in fact we'd need to write lots of code to stop people from being able to rotate windows! That's why we let them (and because rotated windows allways draw attention to our screenscots;-)
But the thing I love the most about fresco is device independance: You give sizes in real word units and have them displayed correctly on your monitor independent of its resolution. You just rerender windows (or parts thereof) once using a so called DrawingKit generating Postscript instead of OpenGL or raster images (both can be used to display on your screen, depending on your graphics card) and have a screenshot.
Regards, Tobias
PS: Yes, Fresco used to be a Toolkit for X. Yes we could do the same and 'fill in the gaps of X', but we do not feel that's worthwhile: We'd need to meddle with lots of code we don't really need to be concerned with (basically all of X;-), we'd add lots of code ourselves since we'd need to duplicate much of the existing code (network layer, device handling, etc.) with libraries we use or our own code. So concerning ourselves with X would slow us down even more then our permanent developer's shortage;-) And I am still convinced that writting a clean display server and then integrating a X compatibility layer ontop of it (like Apple did for example) is the better way to go then to lump even more extensions and toolkits ontop of X. We definitly have enough of those to be a real pita!