Gents, perhaps you already know, FWIW there's an article about a research study that heads to almost the same direction as the "new Voyager": http://www.heise.de/newsticker/Semantic-Desktop-fuer-KDE--/meldung/121519 Cheers, Thomas
Hi all, I have no idea how many people are following this list but I thought it's time for a public update again... As you know the idea is around for quite some time and there is not much stuff released to the public so far. That might make the impression that we do not do anything on the project, but that's wrong :) So just a few words about what is going on: - at Warpstock Europe we had some extremely interesting talks about the design of Voyager. We did quite some drastic changes in the concept itself but I am pretty sure we found the holy grail now from a design point of view now :) - this change requires quite some changes in the prototypes done by Chris Wohlgemuth so far. Our goal is to have something that proves our idea early 2008 (Maybe April or so). I don't know yet if this proof of concept/prototype will be public or not, that will be decided by the core team when we are ready - once we know that our idea works, we will need money to implement it. And I mean a lot of it. After playing around with that idea for about 2 years I'm more than sure that it will never see the light of the day if we do not get some massive funding I will try to add more information about Voyager to the public the next weeks before new year, I started enhancing the page at netlabs.org a bit and I cleaned up the FAQ, which had some really old information in there. http://voyager.netlabs.org(Continue reading)
Just for the record (and for discussing), here are my thoughts I've described to some ppl at #netlabs. So, as I was reading through http://wiki.netlabs.org/index.php/Voyager_API_Design#System_Component_Configuration , I did not understand it fully (or better, misunderstood it), and it turned out to be this: What about making the System Component Configuration part more generic, and thus, more flexible? Instead of being able to manage a fixed set of configurations, I thought that system components could register in there, telling that they are available, and they have this and that configurable setting. This could be even more stretched, so that not only system components, but any kind of applications and/or modules could register in there, so the user could see a list of configurable modules (installed applications, maybe?), and configure all of them in a centralized place, in an uniformed way. Any thoughts? Doodle
As a follow up to a private mail sent out to some developers I open a new thread in here with a stripped down version of the mail. Voyager API discussions take place here: http://wiki.netlabs.org/index.php/Voyager_API_Design - Containing the design/coverage of the upcoming Voyager API http://wiki.netlabs.org/index.php/Voyager_API_Basics - Containing the basic ideas for the Voyager API http://wiki.netlabs.org/index.php/Voyager_API_Design_Guide - Containing the methods and rules for implementing the Voyager API All other pages regarding Voyager can be found in the Voyager category: http://wiki.netlabs.org/index.php/Category:Voyager Please also have a look at the presentations of Chris, Christian and me at the Developers Workshop (the audio tracks are unfortunately broken(Continue reading): Netlabs Object Model: ftp://ftp.netlabs.org/pub/events/DWS2007/presentations/NOM.ZIP Resource Handling: ftp://ftp.netlabs.org/pub/events/DWS2007/presentations/resource.zip The Voyager Project: ftp://ftp.netlabs.org/pub/events/DWS2007/presentations/Voyager-dws2007.pdf
I'm disappointed that at least some degree of binary capability is not one of your current goals. I have several 3rd-party OS/2 packages that I don't have source for, and can think of many others. Examples: IBM PL/I for OS/2 compiler PCOM Personal Communications Book Manager for OS/2 DB/2 universal database This is your project, you can set whatever goals you want, but my feeling is that without binary compatibility you will be severely limiting possible uses and users of the new O/S.
Hi all, There were no more comments about the license so I propose the following summary: * Core components of Voyager: - released dual-licensed under the CDDL and LGPL * Sample Applications & Templates - released under the Apache License 2.0 URL: http://www.apache.org/licenses/LICENSE-2.0 - there is a sample about what you have to add to your source in there. I think the Apache License indeed makes sense for sample applications, like this we do not restrict anything there and the developer can do whatever he/she wants. Mozilla.org provides some templates for the tri-license of the Mozilla code, I took this as base and changed it for the CDDL/LGPL dual-license. The original is here: http://www.mozilla.org/MPL/boilerplate-1.1/ and my proposal for our version for c-files: http://www.netlabs.org/CDDL/cddl-dual-license-c Please comment! If I don't get any feedback I will do it like this :) I didn't really get yet what we have to add in the The Original Code is __________________________(Continue reading)
Hi all, I finally read some licenses today and googled a bit for more information. Licenses I covered: - MPL 1.1 - http://www.mozilla.org/MPL/MPL-1.1.html - CDDL 1.0 - http://www.opensolaris.org/os/licensing/cddllicense.txt - Apache License 2.0 - http://www.apache.org/licenses/LICENSE-2.0 - BSD License - http://www.xfree86.org/3.3.6/COPYRIGHT2.html#5 - APSL - http://www.opensource.apple.com/apsl/2.0.txt I did not read the LGPL I recommend you to at least read this link for the licenses: http://www.fsf.org/licensing/licenses/index_html It's by Stallman so for sure he doesn't like any of the licenses mentioned but it gives some good comments anyway, I simply interpret them different(Continue reading)For the CDDL he isn't too happy about the IP term, please read http://www.gnu.org/philosophy/not-ipr.xhtml as well. Then I found a nice reading about MPL vs. GPL: http://www.croftsoft.com/library/tutorials/gplmpl/ This is a must read, please read it carefully.
Hi, Found the following paper: <http://www.tudos.org/papers_ps/feske-nitpicker.pdf> It describes how to implement a secure GUI server to prevent attacks by trojans etc. Might be a good reading because some ideas are the same we have for voyager like giving just a surface to the client and the client paints into it. One thing I don't like about the approach is that there is no focus switch for windows other than initiated by the user. While ok from a security pov it limits us as developers while implementing an advaced UI. I propose to mark windows don't having the focus specially. In OS/2 and windows this is done by different titlebar colors for active and inactive windows. Having a compositor with translucency we may implement a more radical distinction. For example making every nonactive window translucent to a certain degree or shade it with a different color. One may go even further and shade the background windows depending of their position in the window stack. For example make the lowest window the most translucent one the one on top of it a little bit less etc. Another distinction for the order of windows may be the contrast(Continue reading)
Hi , Has anyone contacted the company http://www.cef-it.de/pages/en/cenew_software.htm ( possible source of contact info is : martin <at> -DeSpam-os2world.com ) regarding whether they would assist with the voyager project ? It seems that they have significant SOM and WPS development experience and according to their FAQ the have experimented with MACH 3 (Darwin) type OS's supporting OS/2 API's See below : [ // Will PAF be a stand-alone OS one day? PAF is tailored to OS/2 and uses this operating system as base platform. This will not change. If we planned to distribute a new OS then we would have to program our own and then adapt PAF to this new platform or licence OS/2 for the distribution. We will definitely not prepare software distributions with OS/2 included, so we would have to step into OS development. We have started experiments with a CMU Mach 3 microkernel OS ported to x86-compatible CPUs with very simple OS/2 servers but we currently have our focus on PAF. Besides we will use a combination of PAF and OS/2 on our new PC systems as embedded solution, so you have a kind of new OS/2 on these systems (but only on these; yes, that is the Macintosh approach, but with an OS/2 extended by PAF). ] The also have developed a new Object Rex interpreter for OS/2 from the Open Rex sources recently posted to the OpenRex effort by IBM. A collaboration with this group would be valuable to the ECs effort and Voyager developemnt,(Continue reading)
Hi All, after successfully running a cairo sample application on the glitz backend, I noticed, that glitz itself has backends. So far there are egl, agl and glx implemented as glitz backends. This means, we probably will have to implement our own backends for glitz. For example one that runs on the linux device framebuffer with OpenGL support, and one that draws to some OS/2 framebuffer (don't know how stuff works there). For the linux side, there exists an interesting sub-project of the mesa3d project. It's called Mesa fbdev/DRI and does exactely what we need. It provides hardware acceleration, draws into the linux frabebuffer device and needs no X server running, and no xlib! Maybe, there exists something similar for OS/2... cheers lexip
 |
|
|
|
|
|
|
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 |
RSS Feed1 | |
|---|---|
1 | |
5 | |
7 | |
4 | |
1 | |
2 | |
1 | |
1 | |
3 | |
2 | |
10 | |
20 | |
1 | |
3 | |
2 | |
12 |