The problem with creating a manual like the Mac User Interface
guidelines is that it requires a lot of effort just to write the
document.
Once the document has been written, applications must implement
various of the user inteface features. The lack of resources in the
free software world to produce this kind of documentation is the most
important problem.
One of the approaches we have taken in the GNOME project was to add a
pieces of the user interface consistency through the GNOME libraries.
Various pieces in the libraries are nothing but programming sugar, and
they achieve two things: simplifying program development and helping
to create same user interfaces.
GNOME contributors realize the importance of this and other issues in
user interfaces. Our approach so far has been to follow the
guidelines from existing systems and try to bring the best user
interface experience details into GNOME. Discussion usually happens
on the various forums about specific user interface improvements.
A year ago, the GNOME UI team was created to help coordinate the
development of user interface issues in GNOME: to write a manual, to
write guidelines, to point out problems in current applications, to
point out desired improvements in applications and so on.
The GNOME UI team has been very successful. Various of the UI changes
you have seen in the October GNOME release (last october) and in the
Bongo GNOME release (last may) were prompted by the UI team.
The UI team is lead by Jim Cape, who takes the input from participans
on the GNOME UI mailing list and presents the suggestions to
the actual developers.
Anyone can help improve GNOME and help the GNOME UI team. User
interface experts from Eazel and Helix have been working with the team
for some time now: both helping and implementing those ideas.
You are right: finding information about the UI team is not easy. I
would love to see changes in the GNOME website to more easily direct
developers to this important resource.
You can read more about the User Interface team here:
http://developer.gnome.org/gnome-ui/
Each port open is a CORBA connection from an application that supports being controlled through CORBA.
To access those services you do have to know the secret password (which is generated once for each session) so it is basically as secure has being able to log into your computer.
Now, we realized that this was a potential problem and some systems are shipping with ORBit CORBA sockets disabled (Helix GNOME ships with a disabled CORBA socket connection) as well as other distributions that have turned this feature off.
If you want to play it safe (although no security holes are known to exist in ORBits incoming processing path) you can put this in your/etc/orbitrc:
I was asked once at Usenix, once at OLS "How long have you been using Unix?". At OLS someone just assumed I was a newcomer that had used a Mac all its life, that I had no idea of what I was talking about, and that I would be better of clicking icons on my Mac.
I have been using Unix since the early 90s. My first contributions to free software was in 1992.
I was the main author of the GNU Midnight Commander, a file manager that was a clone of the DOS file manager called the Norton Commander.
Later, I started working with David Miller on the SPARC port of Linux: I worked on the kernel and on a bunch of device drivers that made the system usable. I also ported three libcs and did significant work on the various dynamic linkers used on the port (the libc4, the libc5 and worked partially on the GNU libc port).
Afterwards, I worked with Ingo and Gadi on the Linux software RAID-1/4/5 implementation. Ingo later perfected it to the beautiful levels you see now.
Later I joined the Linux/Indy team in which I worked on various tasks to bring up a complete system to Linux on the Indy. I abandoned the work when I began working on GNOME, three years ago.
Well, the "integration" of Linux Mandrake of Helix GNOME is really sad. There is no single day that passes without Jacob receiving mail for the broken way Mandrake distributed Helix GNOME.
There are well known ways of working around the problem you describe. Basically, you want to avoid changing interfaces once they have been published.
For instance, the published interfaces in Microsoft Windows have not changed since they were published in the first version of OLE 2.0.
When Microsoft has expanded the funcionality they have created new interfaces or new methods, and they have retained the behaviour and previous interfaces.
The DLL problems in Microsoft applications are of a different nature, and can not be attributed to faults in their component system. It is a separate problem, still a problem for end users, but a separate one.
We have reduced all the complexity that you have described above now. To install, setup and configure your whole system:
lynx -source go-gnome.com | sh
We take care of the library issues for you, and you can focus on compiling Galeon (which we plan on including on Helix GNOME as well in the near future).
Currently Evolution does not have any Exchange support, but we are planning on supporting Exchange in the future.
We realize this is important and there are a number of ways to fully support Exchange that can be done. We will implement the one that makes most sense. We are aware that the lack of support for Exchange protocols will hinder the adoption of Evolution.
The problem was not actually that CORBA was unreliable --despite the KDE people repeating this over and over-- but that they chose to use CORBA as a transparent layer for inter process communications: they assumed that CORBA invocations had to be equal to function invocations, and that failures would never happen and that they should not happen.
Their code was not prepared to deal with failures across CORBA invocations (for example, invoking a CORBA method on a dead server and handling the fact that the server died).
Basically, it required each CORBA invocation to be handled by try {} catch blocks, but my guess is that they assumed they did not have to use that.
Another option I heard later from someone who claimed originated from Torben --which was even more sad-- was that they wanted to "check" for the service before invoking the method to avoid a crash (or my guess is to avoid the try{} catch blocks).
Part of the services that Helix provide for the packages we ship is the updating service: this is a service that lets people deploy fixes, improvements, and new GNOME packages in their system with a simple to use user interface.
Currently our updating service works with RPM and Debian packages (In Debian we just use the great apt infrastructure to achieve this), but other platforms do not have very sophisticated packaging systems that support upgrading and that support vendor tagging.
Building software with RPM is very good, as we can keep the original source packages plus all the patches required as well as the detailed instruction list of how the package was build in a single location (the Source RPM).
This is what we used to do the Solaris port of Helix GNOME. And naturally, RPM produced RPM packages, which we could easily integrate into our updating service.
Using Solaris packages would be an option, but by the time we were done with the packages, it was too late on the release cycle to add support for Solaris packages (not to mention that Solaris packages are not as powerful as RPM packages).
Hence, we decided that it was in the best interest of end users to use and distribute RPM packages for this release in Solaris. This might change in the future though.
That is correct. GNOME is still not ready for the general public for consumption. Not just yet. But we do acknowledge this problem, and we are working towards addressing those issues: redoing the user interface elements that are not trivial to understand, using better wording, giving a better visual layout, redoing things so that they are conceptually cleaner, and easier to understand. But our work does not stop there. We are doing new applications, adding new features to the system (user-level for instance, historic configuration) that will provide the GNOME user with a better user experience. As any other technology, we are still on the early days of GNOME, and people using GNOME are still early-adopters of this technology: the GNOME team is working very hard to make GNOME ready for everyone, and bringing free software to everyone. With your help (providing good bug reports if you are not a programmer, documentation improvements, constructive comments, code, patches, contributions, enthusiasm) we will be able to achieve this goal sooner than later. Miguel.
The naming service is implemented. Indeed, it is implemented as a reusable library, so you can implement different naming systems. For instance, we have a Desktop naming system running in GNOME in the gnome-name-service process.
The implementation repository has never been part of the CORBA specification, it is only talked about, but no details exist. It is left to the implementation.
In the case of GNOME/ORBit, our gnome-name-server plus the GOAD provide the equivalent of the Implementation Repository.
Further, in GNOME 2.0, we have a more extensible facility called the Object Activation Framework (OAF).
There is no event service available now, nor interface repository (although there are protypes for both of them).
Indeed. You need to use Nautilus and see a demostration of a normal person using Nautilus to appreciate the ease of use.
Andy did a demostration at the Guadec conference a few months ago of Nautilus and people were pretty impressed.
We saw his prototype last summer, and back then it was already very interesting, it already was a testbed for new ideas (things that I had not seen before). Describing them is hard, as they were very smoothly integrated into the system, things just "worked".
Good idea. I have requested the Helix GNOME team to add this feature.
If you want features added to GNOME or changes made to the Helix GNOME distribution system, please use the "bug-buddy" program to submit a request (or a bug report).
Bug buddy is available from the GNOME foot menu, or from the desktop "Bug Report Tool" icon on the desktop.
This helps us keep track of existing problems in GNOME, and provide feedback to the users on what the status for the problem report is.
OLE2 did not include those. ActiveX later added those, but our models are significantly different at that stage, that it did not make sense to use the OLE2 interfaces.
For example, Bonobo embeddings are model/view based, while Microsoft ones are based on the IDraw and IDraw2 interfaces. The property pages are very limited and useful only for their setup.
Our property pages, toolbar exchange (embedded controls) all use our Bonobo::Control interface. The "core" model took a lot from Microsoft, but many things did not make sense at higher levels.
Bonobo is definetly designed to let hook up new interfaces (for instance, Evolution defines various new Bonobo interfaces, just like Gnumeric defines a fairly large set of Bonobo interfaces that are spreadsheet-specific).
The reason you need to be able to execute VB code in Excel spreadsheets is that very large sets of code have been written for various sheets in the Excel world. Neither you nor I probably care.
But people doing heavy-weight work with Excel do, and that is stopping them from migrating to a free software platform. Jody, one of the main Gnumeric hackers and Michael Meeks can tell you more about this.
That being said, the GNOME Basic implementation is a sandboxed version of Visual Basic (just like Java) unlike the Microsoft version.
Btw, TeX is a turing-complete language, and people are known to write fairly extensive TeX scripts (and yes, those appear on day to day research papers written in TeX).
TeX while processing your files can request user input to fill in values.
The features being copied are not being copied because we think it is "exciting" to copy the feature, or because we want to be check-to-check feature complete. They are required due to large packages that depend on that. Ask any serious Excel user.
We will do everything withing a legal framework to provide users with the best software out there. Hopefully we will not have to reverse engineer a lot of Microsoft code.
The sooner we can infiltrate them, and obviate the need for proprietary protocols the better. I see a bright future for you as a GNOME/Evolution contributor.
Of course, fighthing bills like the UCITA is important for american citizens, to avoid getting more of the rights taken away.
Evolution Model/View split (the split between the user interface and the actual data, which is running as a separate process (The Wombat)) was designed precisely to solve this problem correctly.
The information displayed on Evolution is not actually loaded into the GUI application you load, it is all handled by a separate process (The Wombat), and the way the code works is by making notifications to the user interface process when data in the wombat changes.
The Palm Pilot syncing tools work without even launching the GUI application, they just talk directly to the Wombat, and sync with the Wombat.
Now, our filtering system is pretty advanced, internally it uses a Scheme like system that is evaluated at various stages of the life of a mail message (reception, delivery, archival, indexing) the rules are applied and a number of actions can take place at each stage. This is used to create the regular "folders" that people are used to.
Another extra option are the "vfolders", these are folders constructed on the flight from a query to the mail database. For example, you could construct a folder with the last 10 messages from your wife that contain the word "Dont forget to bring home..." or all mail you have sent to a mailing list that was CCed to rms for instance.
Slashdot Mirror
The problem with creating a manual like the Mac User Interface
guidelines is that it requires a lot of effort just to write the
document.
Once the document has been written, applications must implement
various of the user inteface features. The lack of resources in the
free software world to produce this kind of documentation is the most
important problem.
One of the approaches we have taken in the GNOME project was to add a
pieces of the user interface consistency through the GNOME libraries.
Various pieces in the libraries are nothing but programming sugar, and
they achieve two things: simplifying program development and helping
to create same user interfaces.
GNOME contributors realize the importance of this and other issues in
user interfaces. Our approach so far has been to follow the
guidelines from existing systems and try to bring the best user
interface experience details into GNOME. Discussion usually happens
on the various forums about specific user interface improvements.
A year ago, the GNOME UI team was created to help coordinate the
development of user interface issues in GNOME: to write a manual, to
write guidelines, to point out problems in current applications, to
point out desired improvements in applications and so on.
The GNOME UI team has been very successful. Various of the UI changes
you have seen in the October GNOME release (last october) and in the
Bongo GNOME release (last may) were prompted by the UI team.
The UI team is lead by Jim Cape, who takes the input from participans
on the GNOME UI mailing list and presents the suggestions to
the actual developers.
Anyone can help improve GNOME and help the GNOME UI team. User
interface experts from Eazel and Helix have been working with the team
for some time now: both helping and implementing those ideas.
You are right: finding information about the UI team is not easy. I
would love to see changes in the GNOME website to more easily direct
developers to this important resource.
You can read more about the User Interface team here:
http://developer.gnome.org/gnome-ui/
Miguel.
Each port open is a CORBA connection from an application that supports being controlled through CORBA.
/etc/orbitrc:
To access those services you do have to know the secret password (which is generated once for each session) so it is basically as secure has being able to log into your computer.
Now, we realized that this was a potential problem and some systems are shipping with ORBit CORBA sockets disabled (Helix GNOME ships with a disabled CORBA socket connection) as well as other distributions that have turned this feature off.
If you want to play it safe (although no security holes are known to exist in ORBits incoming processing path) you can put this in your
ORBIIOPUSock=1
ORBIIOPIPv4=0
ORBIIOPIPv6=0
Miguel
* My Background
I was asked once at Usenix, once at OLS "How long have you been using Unix?". At OLS someone just assumed I was a newcomer that had used a Mac all its life, that I had no idea of what I was talking about, and that I would be better of clicking icons on my Mac.
I have been using Unix since the early 90s. My first contributions to free software was in 1992.
I was the main author of the GNU Midnight Commander, a file manager that was a clone of the DOS file manager called the Norton Commander.
Later, I started working with David Miller on the SPARC port of Linux: I worked on the kernel and on a bunch of device drivers that made the system usable. I also ported three libcs and did significant work on the various dynamic linkers used on the port (the libc4, the libc5 and worked partially on the GNU libc port).
Afterwards, I worked with Ingo and Gadi on the Linux software RAID-1/4/5 implementation. Ingo later perfected it to the beautiful levels you see now.
Later I joined the Linux/Indy team in which I worked on various tasks to bring up a complete system to Linux on the Indy. I abandoned the work when I began working on GNOME, three years ago.
Miguel
The GNOME project was started because of the licensing problems in KDE and Qt: the result was not a free system
Miguel
You are one confused person.
:-)
It is based on COM or whatever name they give to COM these days (COM+
miguel.
Well, the "integration" of Linux Mandrake of Helix GNOME is really sad. There is no single day that passes without Jacob receiving mail for the broken way Mandrake distributed Helix GNOME.
Miguel
There are well known ways of working around the problem you describe. Basically, you want to avoid changing interfaces once they have been published.
For instance, the published interfaces in Microsoft Windows have not changed since they were published in the first version of OLE 2.0.
When Microsoft has expanded the funcionality they have created new interfaces or new methods, and they have retained the behaviour and previous interfaces.
The DLL problems in Microsoft applications are of a different nature, and can not be attributed to faults in their component system. It is a separate problem, still a problem for end users, but a separate one.
Miguel.
We have reduced all the complexity that you have described above now. To install, setup and configure your whole system:
lynx -source go-gnome.com | sh
We take care of the library issues for you, and you can focus on compiling Galeon (which we plan on including on Helix GNOME as well in the near future).
Miguel.
It is a shame you did not sign your message, because I like a lot what you wrote.
Miguel.
Currently Evolution does not have any Exchange support, but we are planning on supporting Exchange in the future.
We realize this is important and there are a number of ways to fully support Exchange that can be done. We will implement the one that makes most sense. We are aware that the lack of support for Exchange protocols will hinder the adoption of Evolution.
Miguel.
You need a clue man.
The interface repository only describes interfaces, it can not discover dynamically interfaces.
Once you have an interface resolved, then you can look up its type definition.
Miguel.
We use standard CORBA profiles, so yes, we can talk to other ORBs, but we do it in a secure fashion.
The side effect you observe means that we wont trust anyone that wants to talk to us. Just those that have permission to talk to us.
Miguel.
The problem was not actually that CORBA was unreliable --despite the KDE people repeating this over and over-- but that they chose to use CORBA as a transparent layer for inter process communications: they assumed that CORBA invocations had to be equal to function invocations, and that failures would never happen and that they should not happen.
Their code was not prepared to deal with failures across CORBA invocations (for example, invoking a CORBA method on a dead server and handling the fact that the server died).
Basically, it required each CORBA invocation to be handled by try {} catch blocks, but my guess is that they assumed they did not have to use that.
Another option I heard later from someone who claimed originated from Torben --which was even more sad-- was that they wanted to "check" for the service before invoking the method to avoid a crash (or my guess is to avoid the try{} catch blocks).
Miguel.
Part of the services that Helix provide for the packages we ship is
the updating service: this is a service that lets people deploy
fixes, improvements, and new GNOME packages in their system with a
simple to use user interface.
Currently our updating service works with RPM and Debian packages
(In Debian we just use the great apt infrastructure to achieve
this), but other platforms do not have very sophisticated packaging
systems that support upgrading and that support vendor tagging.
Building software with RPM is very good, as we can keep the
original source packages plus all the patches required as well as
the detailed instruction list of how the package was build in a
single location (the Source RPM).
This is what we used to do the Solaris port of Helix GNOME. And
naturally, RPM produced RPM packages, which we could easily
integrate into our updating service.
Using Solaris packages would be an option, but by the time we were
done with the packages, it was too late on the release cycle to add
support for Solaris packages (not to mention that Solaris packages
are not as powerful as RPM packages).
Hence, we decided that it was in the best interest of end users to
use and distribute RPM packages for this release in Solaris. This
might change in the future though.
That is correct. GNOME is still not ready for the general public for consumption. Not just yet. But we do acknowledge this problem, and we are working towards addressing those issues: redoing the user interface elements that are not trivial to understand, using better wording, giving a better visual layout, redoing things so that they are conceptually cleaner, and easier to understand. But our work does not stop there. We are doing new applications, adding new features to the system (user-level for instance, historic configuration) that will provide the GNOME user with a better user experience. As any other technology, we are still on the early days of GNOME, and people using GNOME are still early-adopters of this technology: the GNOME team is working very hard to make GNOME ready for everyone, and bringing free software to everyone. With your help (providing good bug reports if you are not a programmer, documentation improvements, constructive comments, code, patches, contributions, enthusiasm) we will be able to achieve this goal sooner than later. Miguel.
Yes, ORBit can be used independently of GNOME.
Miguel.
1. Yes you can: right click on a panel -> panel properties -> hiding -> auto.
2. Alt-Tab traverses trough the various windows on the default setup
Miguel
The naming service is implemented. Indeed, it is implemented as a reusable library, so you can implement different naming systems. For instance, we have a Desktop naming system running in GNOME in the gnome-name-service process.
The implementation repository has never been part of the CORBA specification, it is only talked about, but no details exist. It is left to the implementation.
In the case of GNOME/ORBit, our gnome-name-server plus the GOAD provide the equivalent of the Implementation Repository.
Further, in GNOME 2.0, we have a more extensible facility called the Object Activation Framework (OAF).
There is no event service available now, nor interface repository (although there are protypes for both of them).
Miguel.
Andy did a demostration at the Guadec conference a few months ago of Nautilus and people were pretty impressed.
We saw his prototype last summer, and back then it was already very interesting, it already was a testbed for new ideas (things that I had not seen before). Describing them is hard, as they were very smoothly integrated into the system, things just "worked".
Miguel.
I loved this interview with Andy. Everytime I have had the opportunity to talk to him, I have learned something new.
Miguel.
Good idea. I have requested the Helix GNOME team to add this feature.
If you want features added to GNOME or changes made to the Helix GNOME distribution system, please use the "bug-buddy" program to submit a request (or a bug report).
Bug buddy is available from the GNOME foot menu, or from the desktop "Bug Report Tool" icon on the desktop.
This helps us keep track of existing problems in GNOME, and provide feedback to the users on what the status for the problem report is.
Miguel.
OLE2 did not include those. ActiveX later added those, but our models are significantly different at that stage, that it did not make sense to use the OLE2 interfaces.
For example, Bonobo embeddings are model/view based, while Microsoft ones are based on the IDraw and IDraw2 interfaces. The property pages are very limited and useful only for their setup.
Our property pages, toolbar exchange (embedded controls) all use our Bonobo::Control interface. The "core" model took a lot from Microsoft, but many things did not make sense at higher levels.
Bonobo is definetly designed to let hook up new interfaces (for instance, Evolution defines various new Bonobo interfaces, just like Gnumeric defines a fairly large set of Bonobo interfaces that are spreadsheet-specific).
Miguel.
The reason you need to be able to execute VB code in Excel spreadsheets is that very large sets of code have been written for various sheets in the Excel world. Neither you nor I probably care.
But people doing heavy-weight work with Excel do, and that is stopping them from migrating to a free software platform. Jody, one of the main Gnumeric hackers and Michael Meeks can tell you more about this.
That being said, the GNOME Basic implementation is a sandboxed version of Visual Basic (just like Java) unlike the Microsoft version.
Btw, TeX is a turing-complete language, and people are known to write fairly extensive TeX scripts (and yes, those appear on day to day research papers written in TeX).
TeX while processing your files can request user input to fill in values.
The features being copied are not being copied because we think it is "exciting" to copy the feature, or because we want to be check-to-check feature complete. They are required due to large packages that depend on that. Ask any serious Excel user.
We will do everything withing a legal framework to provide users with the best software out there. Hopefully we will not have to reverse engineer a lot of Microsoft code.
The sooner we can infiltrate them, and obviate the need for proprietary protocols the better. I see a bright future for you as a GNOME/Evolution contributor.
Of course, fighthing bills like the UCITA is important for american citizens, to avoid getting more of the rights taken away.
Miguel.
Evolution Model/View split (the split between the user interface and the actual data, which is running as a separate process (The Wombat)) was designed precisely to solve this problem correctly.
The information displayed on Evolution is not actually loaded into the GUI application you load, it is all handled by a separate process (The Wombat), and the way the code works is by making notifications to the user interface process when data in the wombat changes.
The Palm Pilot syncing tools work without even launching the GUI application, they just talk directly to the Wombat, and sync with the Wombat.
Now, our filtering system is pretty advanced, internally it uses a Scheme like system that is evaluated at various stages of the life of a mail message (reception, delivery, archival, indexing) the rules are applied and a number of actions can take place at each stage. This is used to create the regular "folders" that people are used to.
Another extra option are the "vfolders", these are folders constructed on the flight from a query to the mail database. For example, you could construct a folder with the last 10 messages from your wife that contain the word "Dont forget to bring home..." or all mail you have sent to a mailing list that was CCed to rms for instance.
The possibilities are infinite.
Miguel.