Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
X GUI

Fresco M1 Released 282

Posted by timothy from the actually-not-x dept.
rajan r writes "The first release after 18 months, Fresco, previously known as Berlin, released M1 or Milestone 1. The release notes here, screenshots here. The original 'press release' follows: 'I'm proud to announce that milestone 1 of Fresco (formerly known as Berlin) has (at long last) been released. A lot has changed since the last release, but this isn't that surprising, since the last release was more then 18 months ago; most of the real work for the past few months has been behind the scenes (changing hosts, a new web site infrastructure, improved build system, an issue tracker (hooray!), better documentation (and more to come), etc.). Source (no packages at the moment, but debs will be available soon, and the tree contains .spec files for building your own rpms) The name change. Enjoy! -- Nathaniel '"
This discussion has been archived. No new comments can be posted.

Fresco M1 Released More

Fresco M1 Released

Comments Filter:

  • You know, Fresco...doesn't ring a bell? (Score:4, Insightful)

    by Anonymous Coward on Sunday November 24, 2002 @02:46PM (#4744143)
    Okay, how about Berlin? Still doesn't ring a bell? You mean that you don't know about this obscure package referenced only by unknown product names that the unbelievable overwhelming majority of the public has no knowledge about? Good then, we won't bother including a simple description of what the hell it even is.

    P.S. It's a system for tracking calories from consumed donuts.
    • Berlin originally was started when Xf86 was still in the 3.x and was terrible slow and inadaquite compared to other gui's like Windows and macos.

      Also back in the late 1990's many linux users still used pentium 1's and 486's with only 32 or 64 megs of ram! The client/server nature of X was not only inadaquate but it was considered bloated and obsolete. After all, who runs X on terminals anymore? Luckily this has changed since HP and SGI have both donated code and X came out with dri for much better performance. Without dri even the fastest of machines redrew graphics commands at a slugish rate.

      If a pda and the original mac could have a better gui then X in 1/100th of the memory then it had to go. However today with fast video cards with lots of memory and dri and other improvements all the negatives on X are obsolete or do not matter as much.

      I use to be an X hater untill recently. Berlin is no longer needed except on older systems or pda's. I prefer to not have the complexities of a window manager. But all gui unix apps require X so the point is useless. I do find it redicolous that in 1998 that %80 of my memory was used just for X!
      • X came out with dri for much better performance.

        Errmm.. DRI is not used for X.

        Berlin is no longer needed except on older systems or pda's.

        Rather ironically, it seems that Berlin is also too slow for PDAs due to very heavy use of floating point. (see the text beside the screenshot of berlin on the Zaurus).
      • X seems to use so much video memory because the X server process allocates memory on behalf of tasks using it's services.
        • X mmaps the video mem in it's own process space, show it shows up as a memory hog in ps and top, but isn't.

          e.g. if you have one of those matrox parhelia cards with 256 MB ram in there, X will show up as using at lead 256 MB mem + a little bit. So the reports of X being a memory hog are exaggerated.

          As for Fresco/Berlin, I hope that there will be an X compat layer so all my old apps will run. It's not a strange request. Lots of operating systems that don't usually run X (BeOS, QNX, Mac OS X, Windows, etc.) have an X server available one can install.

          It would be nifty having a rootless X server for Fresco.

      • "Also back in the late 1990's many linux users still used pentium 1's and 486's with only 32 or 64 megs of ram! The client/server nature of X was not only inadaquate but it was considered bloated and obsolete."

        Yea, just as bloated as on my R3k 25Mhz with 16mb of RAM, right?

        Wrong. X11 servers with proper frame buffers ran on stuff wimpier than my Palm Vx with no problems!
        XFree86 has always been the problem. That is why so much work went in the 4.x tree towards making the drivers not suck, and why we're starting to see those efforts pay off.

        Now it just needs a little more in the basic spec to support more modern windowing features, as well as making everything easier to automate. End users don't want to know about copying dot files with X11 auth permissions, they just want a magic "Roam" button which lets them take their desktop elsewhere in the house.
      • Luckily this has changed since HP and SGI have both donated code and X came out with dri for much better performance.

        HP and SGI did not contribute to the DRI.

        Without dri even the fastest of machines redrew graphics commands at a slugish rate.

        The DRI is only used for GLX. Maybe this will change in the future, but Xlib operations today still use the old indirect rendering model.

    • Yeah, I get pissed when I go to sports sites and they talk about all these teams and games and RBI, yards passages and other technical terms. I expect them to explain it to me in every article summary too. Fuckers. Tell you what - you go beat up on the sports sites for assuming you know something about sports, and I'll go beat up on the technical sites for assuming you know something about tech.

      (Oh and I *REALLY* hate the sites that link to other sites that might have further information... like they expect me to *read* something about the subject. Ha! FAQ and search engines? Not for me my bucko - I want it spoon fed!)

      --
      Evan "Played golf and cricket in school, still have only a dim idea of how (American) football works"

    • And of course, we should fill up the front page defining all the terms a minority of users might possibly not know rather than expect you to click on the damn link and find out for yourself.

      Good grief.

    • I think anyone reading slashdot for the past few years would know what berlin was.

      Of course, since slashdot has gone down in quality so much most of the people from long ago are gone (actualy the comments have been getting a little better lately, but the stories are still crappy as hell)
    • I thought it was Freesco [freesco.org] the whole time I was reading the blurb. I kept asking myself, what's with this Berlin name? Then I clicked thru and realized it wasn't...Oh well. I like Freesco better anyways. =)

  • Berlin (Score:4, Interesting)

    by CanadaDave ( 544515 ) on Sunday November 24, 2002 @02:46PM (#4744146) Homepage
    I'm wondering why they changed their name from Berlin to Fresco. Why was it called Berlin in the first place, and what made them decide to change it? Kitchener, Canada used to be called Berlin prior to around 1910 or so. Why is everyone dissing Berlin?
    • My take on the link:

      The program itself is still called Berlin, only the project's name changed to Fresco.

      My first guess at why has proven to be on their list, easy, available, domain name: fresco.org is much easier than berlin-consortium.org.

      Also apparantly there was an old project to make a gui, called Fresco, and the original developers no longer own the rights to that name, so their paying homage to who they stole ideas from.
    • Ooops, I didn't see the link at the end of the Slashdot post.

    • Re:Berlin (Score:3, Funny)

      by __past__ ( 542467 )
      I'm wondering why they changed their name from Berlin to Fresco.
      Ever been in Berlin recently? It's fucking cold there in winter, the natives talk a horrible dialect, public transport is expensive, there are way too much schmocks who love living in the Reichshauptstadt because they could meet Benjamin von Stuckrad-Barre or some other aesthetically challengend famous "artist" in some lousy yuppie bar, and the beer sucks.

      Nobody wants to have his toy project associated with it anymore. It was cool in the 90s, but the times, they are changing...

      • Really? Thanks for the info. I went on a primarily Western Europe tour back in 1999-2000. Didn't see much of Germany, just some of the west, including Munich. I was told the Berlin was the place to be, and that I was missing out. Apparently it was a "happening place". But I guess that isn't true anymore. I have heard Prague is pretty sweet these days (at least according to fellow Canadian back-packers) so maybe I'll skip Berlin and head to Prague.

    • See THIS LINK [fresco.org] in the story.

    • True, Kitchener, Ontario (twin city to Waterloo, which folks on this site are more likely to have heard of) was named Berlin. It was renamed (after Lord Kitchener) during WW I for obvious political reasons.

      And if you'd read the linked article, you'd know why the project was renamed Fresco, although the display server implementation retains the name Berlin.

  • Berlin (Score:3, Interesting)

    by MORTAR_COMBAT! ( 589963 ) on Sunday November 24, 2002 @02:48PM (#4744153)
    I had some early failures trying to get Berlin up and running on my system -- just compiling the (highly unstable) prereqs was a chore, let alone having to upgrade my compiler to compile Berlin. I hope this time around it doesn't take me a week to even "try" it, because I've been a steady believer in the project (well... any project to replace X).

    • Re:Berlin (Score:3, Informative)

      by crimsun ( 4771 )
      If you happen to use Debian Sid, you can basically just apt-get install all the prereqs (well, that's what I'm doing). You may want to install waldi's omniorb4 packages, though. One of the main hitches is the omniorb stuff. Post-M1 defaults to ``-R ior'', and as the release notes suggest, it's highly recommended that you use that switch for both "server" and "clients."

  • Confusion (Score:5, Informative)

    by faeryman ( 191366 ) on Sunday November 24, 2002 @02:51PM (#4744179) Homepage
    If you're like me and have no idea what Fresco does, check out the intro [fresco.org], an FAQ [fresco.org] and FrescoVsX [fresco.org]. I was reading about this project last night, and since Slashdot doesn't really explain what everything is, these provide some answers.

  • Debian packages (Score:4, Informative)

    by Anonymous Coward on Sunday November 24, 2002 @02:51PM (#4744182)
    Debian packages are available from http://non-us.debian.org/~waldi/ [debian.org] . Note that the fresco packages require the omniorb4 packages.
    • Do these work well? Please post here if you have experience with these packages. I'd just like to hear a few comments about them before I try them out. I'm not a hard core user, but I'd wouldn't mind giving this Fresco thing a try, just for fun. After I install these debs, will I have a new selection on my X session manager? I highly doubt it since Fresco is not X! So how to I kill KDM and X, and start up Fresco?
      • You don't kill KDM and XFree86, you just open $TERM and fire up ``berlin -R ior'' (if you compile M1). Think Xnest. I compiled M1 some days ago (debs weren't available then), and I'm still tracking down an omniorb3 problem where connections from localhost are rejected.

        (The debs themselves use -R nameserver, btw, which is why you'll need omniorb4 + the nameserver package. I also can't comment on how well they work, but try 'em!)

  • CORBA? (Score:3, Insightful)

    by khuber ( 5664 ) on Sunday November 24, 2002 @02:52PM (#4744187)
    Am I the only one who thinks CORBA for local system calls is gross? I wonder what the overhead to draw a pixel is like.

    (Okay, actually I think CORBA is gross, period.)

    -Kevin

    • Re:CORBA? (Score:4, Insightful)

      by obi ( 118631 ) on Sunday November 24, 2002 @03:12PM (#4744333)
      Except that Fresco doesn't use calls to draw a single pixel.

      It's the single issue that people take most issue with - it's truly bizarre.

      If Fresco needed to drop CORBA they'd have to reimplement a system similar to CORBA to have the same features, only to satisfy NIH syndrome. And they'd drop all the work that has gone into CORBA's design _and_ implementations (there's some good well performing ORB's out there)

      In other words, CORBA is a good fit for a project like Fresco.

      Check out these links with some answers to your question

      - http://wiki.fresco.org/index.cgi/ArchitectureQuest ions
      - http://wiki.fresco.org/index.cgi/MicroGUI
      - http://www.fresco.org/introduction.html

      • Re:CORBA? (Score:2, Insightful)

        by khuber ( 5664 )
        I realize that Fresco is high level and vector-based. The pixel question is just to see what the most extreme overhead would be. But then again, how would Fresco support games running in a window?

        I'm just not sold on the idea of using CORBA for a component model in this manner. Gnome does this too so it's not a new idea to me. I have read many arguments, but I'm still skeptical. Why can't I have a proxy API that makes local library calls or CORBA calls, depending on what is needed? A language that doesn't want to call native code can use CORBA. There are also some "philosophical" issues about the realities of network transparency as I mentioned in another post.

        -Kevin

        • But then again, how would Fresco support games running in a window?
          >>>>>>>>
          Most likely how X supports it: bypassing the protocol via something like the DRI.

        • Re:CORBA? (Score:3, Insightful)

          by obi ( 118631 )

          For things like movie playing they'd take a shortcut indeed (SHM). I found this in http://wiki.fresco.org/ArchitectureQuestions

          "... In the exceptional case that a client application requires serious bandwidth to the videocard and there is a good reason not to move drawing code to the server (like, say, a game) there's nothing preventing an X-like shared memory segment from being negotiated between the client and server. ..."

          I think that's what's being done when using XGGI in Berlin (running X in a window in Berlin)

          As for what Gnome does - imho they're using corba as a network protocol, not what corba was intended for. They write wrappers (bonobo) around the corba binding (admittedly this is necessary because the C corba binding is horrible)

          As for your comment: "Why can't I have a proxy API that makes local library calls or CORBA calls, depending on what is needed?" - a decent ORB does this already for you.

          OmniORB4 is a very well-performing and compliant (and GPL) ORB - they state on their webpage (http://omniorb.sourceforge.net/cgi-bin/moin.cgi/O mniOrb4DevelopmentStatus)

          "... When a servant for an object is in the same address space as the client, omniORB uses a colocation optimisation that makes the call significantly faster than a remote call. However, to adhere to the CORBA specification, there is still a fair bit of work involved in a local call, including locking to make sure everything is thread safe, per-thread data access for POACurrent, and all sorts of other things. This adds up to mean that a colocated call is significantly slower than a direct virtual function call would be.

          omniORB 4 supports a proprietary POA policy that allows local calls to shortcut all of this, resulting in local calls that are almost as fast as virtual function calls. ..."

          Fresco has used this "shortcut" and it can speed everything up quite a bit.

    • Re:CORBA? (Score:2)

      by Gleef ( 86 )
      khyber asks:
      Am I the only one who thinks CORBA for local system calls is gross? I wonder what the overhead to draw a pixel is like.

      Several portions of GNOME, including the GNOME panel, use CORBA for local system calls. It's not quite as responsive as direct X calls, but even on a K6-400 I find it quite usable.

      Desktops are so overpowered in regards to normal use, it's perfectly reasonable in my mind to use some of that power to make things:
      1) More flexible
      2) Easier to develop

      Fresco might just offer that :-)
    • CORBA is not reaally overhead - it works fine in GNOME. But CORBA is obsolete. The main problem is that CORBA was not designed for asyncronous messaging from the first place. And that is bad in a real world with real firewall admins.

      I think SOAP is much better than CORBA to bring a network transparency to GUI. SOAP is more flexible and more language independent (People who tried CJava comm over CORBA will understand).

      Unfortunately, SOAP has problems too:

      • SOAP will give more overhead if you'll try to use it to deliver individual pixels and mouse events. Although, it's a solvable and configurable tradeoff between latency and overall performance.
      • Today SOAP is controlled mostly by Microsoft. I doubt that company will contribute anything to any good open source project. Although, Microsoft itself has some chance if they'll try something like GUI.NET
      I wonder if Mono will be capable to sustitute X in future.

  • gui (Score:4, Funny)

    by SigmundK ( 551485 ) <vile-dmg@online.no> on Sunday November 24, 2002 @02:54PM (#4744210) Homepage Journal
    personally, i'm waiting for the graphical server previously known as prince.

  • An intro that actually introduces would be helpful (Score:4, Informative)

    by Phouk ( 118940 ) on Sunday November 24, 2002 @02:55PM (#4744215)
    Really, half a sentence of what this Fresco is about would have been helpful in the introduction - e.g. "Fresco is a windowing system derived from a powerful structured graphics toolkit" (from the page). This would save readers not familiar with the project from having to click on the article to find out whether it interests them, and it would reduce the slashdot effect a bit.

    I know, it's a novel concept, an introduction actually introducing the readers to the subject...
    • I agree, an intro as to what Fresco is would have been useful. And would probably have saved the owners of http://www.fresco.org/ loads in bandwidth costs. I'd suggest that the slashdot editors consider a brief introduction on each article or lay down some guidelines when posting articles so readers aren't doing a lot of headscratching. Luck!

    • Re:An intro that actually introduces would be help (Score:4, Insightful)

      by Mark Bainter ( 2222 ) on Sunday November 24, 2002 @06:21PM (#4745710)
      Heh. I find this attitude bizzare. This is a news site dedicated to a specific market. Chances are, if you're in that market, you know what berlin is. However, if you don't, you can go look, that's the beauty of having the link in the story.

      So, do you make comments like this on CNN? "Where the heck is Israel and what's the big deal about the west bank? Sheesh, can't you guys put a short history lesson about each area and the conflicts involved in every article?"

  • Some basic facts: (Score:5, Informative)

    by t_hunger ( 449259 ) on Sunday November 24, 2002 @02:57PM (#4744219)
    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.

    Regards,
    Tobias
    • *) 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).
      That's just cool. But is the zoom factor for the whole desktop or individual programs? Being able to scale a spreadsheet to see more of it while keeping Word Processing normal would be nice. :)
    • Yes, Fresco uses CORBA and it is a good thing.

      I haven't used CORBA, but the two distributed systems PhDs I've worked with gag every time I mention it. I figure that there has to be something wrong there. Plus, this thing has to do parameter marshalling for even local calls? :-(

      We do not write drivers

      After reading the FAQ, I'm afraid I still don't understand what is hardware accelerated here. If I want to render a translucent, rotated window, is this done in software?

      we'd need to carry along tons of code we do not need...xlib

      I wonder whether it's reasonable for only 24 bit color to be used. Half of xlib is palette/color space management.

      • CORBA (Score:2)

        by avdi ( 66548 )
        If it helps explain it at all, CORBA isn't known for being used by PHds. It's generally used by engineers in software companie3s trying to get real work done. Which is not to say that there's anything wrong with being a PHD; just that the academically oriented and the pragmatically oriented tend to use very different measures when determining a technology's worth.

  • It's been a long time... (Score:5, Informative)

    by jregel ( 39009 ) on Sunday November 24, 2002 @03:03PM (#4744266) Homepage
    I have watched the Berlin project for several years, remembering the initial idea to create a graphical system written in Assembler, a change of project leaders and the decision to use CORBA.

    I don't think that Fresco will replace X anytime soon, if ever, but it's an interesting technology demo that will surely influence other projects. Playing around with the Quartz technology in MacOS X has convinced me that better and more interesting ways of doing graphics are possible - the Fresco project, by using device independent rendering (OpenGL / Postscript) and an ORB merges some of the advantages of X and DPS / Display PDF.

  • Why the name change? (Score:2, Informative)

    by NoMercy ( 105420 )
    And why did they choose a name which is already used by someone else, for a embeded systems web-browser
    Ant Fresco [antlimited.com].

    • Re:Why the name change? (Score:4, Informative)

      by t_hunger ( 449259 ) on Sunday November 24, 2002 @03:19PM (#4744382)
      Because we stole most of our ideas and lots of the code from Fresco, a former Toolkit developed by the X-Consortium. We decided that we should adopt that name after getting very far from the original Berlin-ideas: Assembler, non-portable, as fast as possible on top of GGI.

      We meat the last maintainer from Fresco a couple of times, he told us it's fine with him for us to adopt the name, we got the domain, ...

  • Getting higher speeds out of Linux graphics (Score:4, Insightful)

    by FeatureBug ( 158235 ) on Sunday November 24, 2002 @03:18PM (#4744373)

    In an earlier comment somebody said, "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)."

    X may be good but sometimes it is simply too slow and, worse, the documentation does not go out of its way to explain properly the speedups that are available.

    Ok, there's shared memory pixmaps and shared memory images [reptiles.org] but the documentation is incomplete.

    When you need speed and don't care about hardware-dependency you can use Direct Graphics Access module - DGA. But where's good documentation for DGA? Is there anything faster than DGA in X? Where's the good documentation?

  • When will Xrender be completed? (Score:4, Interesting)

    by HanzoSan ( 251665 ) on Sunday November 24, 2002 @03:25PM (#4744415) Homepage Journal
    I bet Fresco will be finished before Xrender has image transformations, true hardware alpha channel, etc.

    X is just now getting anti alaised fonts and everyone is saying X is so great, we are about a year away from the release of Xfree5.0 which is supposed to have the finished Xrender, only one guy is working on Xrender (Keith Packard)
    The founder of the X project Mr. Dawes claims they are just now beginning to focus on

    Quotes from David Dawes David Dawes: There has been some work on a new rendering model for XFree86 that provides some more advance composition techniques (including transparency), this currently being implemented in software. For XFree86 5.0 we'll be investigating this as part of our review of rendering models, and seeing if a hardware implementation would not be more appropriate.

    Currently Xrender is still in the planning stages, its at about the same level as Fresco, not really useable to anyone but perhaps Keith Packard and a select few developers, its unfinished, its beta but to users and not so skilled programmers its vaporware.

    I'm looking towards XFree86 5.0, which will be the next significant step in XFree86. We're only just starting to think seriously about it. We'll start by re-evaluating what we would like from a graphics/windowing system, and not limit ourselves to the ones that currently exist. With XFree86 4.0 our main focus was on the device-dependent component of the X server (DDX), and to do that we needed to provide a more modular infrastructure. The features that came out of that process showed how much it was needed, and it has given us a solid DDX base from which to expand into other areas. For 5.0 I expect that we'll move more into the device-independent (DIX) and protocol areas as well as making some adjustments to the DDX area based on our experiences with 4.x.

    Ok so for Xfree86 5.0 they will focus on improving the rendering, and bringing X to the levels of Aqua, but by the time 5.0 gets here expect Longhorn to be released, and expect OS 11 to be released by Apple which takes things to the next level.

    Linux needs to do more than just keep afloat and compete, Linux has to dominate to beat Microsoft.

    Currently the only thing preventing Linux from taking the desktop market, is the fact that the currently Linux interface doesnt look polished enough, theres enough programs for grandma, theres games, theres plenty of office apps, the casual user can use Linux, the only reason they wont use Linux is because OSX is better than Linux.

    Why buy a Linux dell laptop for college when you can get an Ibook thats just as powerful but better?

    Why get Linux if its just like Windows? This is why Windows users would sooner switch to Mac.

    X is now one of Linux's biggest bottlenecks, along with the fact that they have no music apps and not enough file sharing apps.
    • I bet Fresco will be finished before Xrender has image transformations, true hardware alpha channel, etc.

      Why bother with XRender when there's the proven GLX [sgi.com]?
      • Honest query: I've thought of this myself, and wonder what problems there may be to implementing a UI toolkit (such as GTK or QT) so that it uses GLX to render the widgets, rather than the current method. (Since making a window using GLX is fairly close to a no-brainer; but how to take an app like GIMP or Konq and putting the entire app onto the GLX extension is a mystry to me...)
    • X is just now getting anti alaised fonts and everyone is saying X is so great, we are about a year away from the release of Xfree5.0 which is supposed to have the finished Xrender, only one guy is working on Xrender (Keith Packard)

      RENDER is basically done. What you're thinking of is, we don't have true transparency yet. Well what do you know, that's because

      a) Transparency is useless for virtually anything except screenshots, making a list of places where it enhances usability for instance is very hard.... and

      b) X has bigger issues which need resolving first, like on the fly resolution switching (R&R, done), decent cursors (XCursor, done), reducing the amount of configuration work needed (ongoing, the aim is to eliminate the XF86Config file eventually).

      And FYI the Matrox drivers already have hardware accelerated alpha blending.

      People make such a big deal of having "true" transparency, but you know what? I'd probably turn most of it off. Truly transparent terminal windows I find are harder to use than the desktop wallpaper transparency that KDE and GNOME use. One shows you all the text, lines etc, the latter just gives you a nice working background. Maybe if they were blended as well to make the background less distracting, that'd be cool, but at the end of the day it's just FUN, not USEFUL.



      • Linux looks like shit because it has no Alpha channel effects, Note I didnt say transparency, thats not what I mean, what I mean is, the ability for windows to have diffrent levels of alpha channelling.

        This is VERY useful, look at OSX and see how its used, even WindowsXP uses it when you move your icons, the icons become transparent so you can see where you are moving them.

        The cursor also needs to become transparent so that it can have proper shadows and look professional, the fonts would also look better, along with the windows.

        This isnt about usability, geeks care about usability, WindowsXP isnt the most usable, neither is OSX, you have to balance usability and presentation.

        Linux is already easier to use meaning better usability than Windows in most areas, the only real problems left are the lack of polish, Linux still looks amateur, KDE3 can add all these nice effects but if they all are fake, the whole thing looks like a hacker OS that it still is.

        Things need to look professional, and this is the purpose of eye candy.
        • First, the ability of windows to have different alpha values *is* transparency (more appropriately translucency). It *is* useless.

          This is VERY useful, look at OSX and see how its used, even Windows XP uses it when you move your icons, the icons become transparent so you can see where you are moving them.
          >>>>>>>>>>
          Um, how exactly is this useful? First, I doubt you can make out two tiny icon-sized images alpha-blended together. Second, if you're drop target is the size of an icon, there is some serious design error. Besides, Linux has it too. I don't have desktop icons in KDE (I hate icons) but if I did, they'd be translucent when moved.

          The cursor also needs to become transparent so that it can have proper shadows and look professional,
          >>>>>>>>>
          Um, shadows on cursors looks cheesy, not professional. Are you telling me that before Windows 2000 and it's drop shadow effect, there was no professional looking GUI? Beyond that, you're just wrong on so many levels. All cursors (since like Windows 2.0) have transparency (they're two bitmaps, a color one and a mask). That's why it looks like an arrow rather than a big square. Besides, the XCursor extension (already in XFree CVS) does drop shadows and animation and all that.

          the fonts would also look better, along with the windows.
          >>>>>>>>
          Um, translucency at the screen level (which X doesn't support) has nothing to do with translucency at the window level (which X does support, via XRender). Translucency at the screen level is needed for window drop-shadows, while translucency at the window level works just fine for anti-aliased text. On top of that, my AA fonts look better in X than in Windows, and a hell of a lot better than OS X.

          This isnt about usability, geeks care about usability, WindowsXP isnt the most usable, neither is OSX, you have to balance usability and presentation.
          >>>>>>>
          Usability is king. If something can look nice and still be usable, great. If looks interferes with usability, you've fucked up the design.

          KDE3 can add all these nice effects but if they all are fake, the whole thing looks like a hacker OS that it still is.
          >>>>>>>>>
          How is it fake? I've got transparent menus and cool eye candy in KDE, and I sure as a hell can't tell the difference between it and OS X, aside from the god-damned window drop-shadows. There are two rendering models at work here, and despite what Apple would have you believe, Aqua's isn't better than X's.

          X has a model that maps very well to current hardware, and is very fast. Do benchmarks if you don't believe me on the 'fast' part. I've done them, and X whips some ass. As a trade-off for this, it has to implement certain eye-candy tricks as hacks. This is just fine, because eye candy isn't drawn that often anyway. If the user doesn't notice, it's working just fine.

          Aqua uses a model that does not map well at all to current hardware. It's coupling to DisplayPDF precludes a lot of hardware acceleration possibilities, and it uses inordinate amounts of RAM. However, it enables certain things like window shadows and the genie effect to be done "naturally."

          The major problem with Aqua is it trades "real work" performance for "stupid eye-candy" performance. That's a no-no.

          (Note, I'm just comparing the window rendering methods. Aqua's *real* killer feature is the Quartz vector API, which Apple unfortunately does half-assedly by rendering everything to giant bitmaps...)

          Things need to look professional, and this is the purpose of eye candy.
          >>>>>>>>>>.
          Um, even Apple realized that it had to cut down on eye candy to look more professional. Hence, Aqua Graphite.

  • For God's sake (Score:5, Insightful)

    by qwijibrumm ( 559350 ) on Sunday November 24, 2002 @03:27PM (#4744424)
    Everyone is saying,
    1. "Why?"
    2. "What's wrong with X?"
    3. "It looks like crap."

    Nobody realizes the answers are easy.
    1. Why not? They want a better, simpler windowing environment.
    2. Read the page. There are performance issues, resolution issues, and network issues. They also hope to add an X compatibilty layer at some point.
    3. It's not done, not by a longshot.

    Frankly, a rival project is a good thing. Good luck to Fresco for doing something that no one else dares, writing what could turn in to an X substitue.
  • It would be nice if the slashdot editors would ensure that the slashdot blurbs convey - even generally - what a given project is about. From the slashdot blurb on this, I have no way of telling what "Fresco" is without reading the article. I'm supposing it's a software product (though it might be hardware). I have little idea whether it's a lightweight linux distro, a financial planning application, or a virtual porn site. I don't know if it's free or commercial. I *could* click the article and read it to find out. But I won't, because I'm not that intrigued by a product that I have no knowledge of; there are tons of those.

    .

  • deeper issues (Score:2, Insightful)

    by Anonymous Coward
    Surely there are deeper issues with a Vector based display that is resolution independant... The rest of the computing world does not use this approach, so how do you remain compatible?

    I am not talking about software applications here, but everyday things like webpages (images in a web page are not generally resolution independant) and games.

    Hardware is the same. My monitor is an LCD device with exactly 1280*1024 pixels. With a 100% vector display it would be awful to look at all day. I like the ability to be able to turn on or off 1 pixex, or subpixel, on my monitor.

    You end up with an awful and awkward looking experience just for this "feature" which actually isnt all that important.

    • Re:deeper issues (Score:2, Interesting)

      by curious.corn ( 167387 )
      You end up with an awful and awkward looking experience just for this "feature" which actually isnt all that important.
      Just as sub pixel AA aka cleartype you love so much, rinse the m$ propaganda off and reconsider. This stuff really gives you headaches: the sides of a font have different tints, everything looks like your monitor blew a fuse and no pro graphic will ever have this crap interfere with the color calibration system. Need better edges? Buy a 1600x1200 monitor and stop whining; the fonts are ant like? Increase size; the GUI is screwed Redmond hardcoded the widget sizes? I pity you. BTW, OsX is all about vector based formats from the truetype fonts - oh, but your rest of the computing world doesn't use them - to svg resizable icons and widgets (where the difference between pathetic winblast theming progs and the original really shines)
      I hate to be hard but... are you shure you're a nerd?
      • Amen to that. I run a 1600x1200 15" LCD screen, and KDE doesn't give me a single bit of trouble with it. Everything looks exactly like it should, only sharper. Well designed web pages look just as great. In comparison, Windows just doesn't handle it as well. It certainly doesn't look bad, but you can definately notice that you're using larger than normal fonts because of layout glitches.

  • Comparison to PicoGUI? (Score:4, Insightful)

    by Ian Bicking ( 980 ) <ianb@nOspaM.colorstudy.com> on Sunday November 24, 2002 @04:44PM (#4744975) Homepage
    PicoGUI [picogui.org], discussed here recently [slashdot.org], seems very similar to Fresco. What is the advantage of Fresco over PicoGUI? PicoGUI actually seems to be somewhat usable right now because it has been made for a very practical purpose, and has gotten real use. A library or system that isn't really used has a hard time developing quickly and responding to real (not imagined) needs.

    I think it's also neat that PicoGUI supports multiple (programming) languages simply by having a documented net protocol -- language bindings talk directly with the renderer over the net, instead of wrapping some C interface.

    PicoGUI is also small and cross platform. It's certainly not as old as Fresco, but it looks like they're going to lap Fresco pretty easily.

    On another front -- what's Fresco's comparison to NeWS [art.net]? NeWS, a competitor to X from Sun (late 80's?), had some concepts that were similar to Fresco (and PicoGUI). Considerably more display logic was on the server (renderer). It apparently had lots of bugs and issues, but it actually did reach a usable state. Have they learned from this predecessor? Neither project seems as flexible (NeWS used Postscript for its widgets, so new widgets could be nearly arbitrarily complex)... that flexibility may have been NeWS downfall.

    Anyway, it always seemed like a neat idea and an important project to learn from.

    • Why not have a look at the FAQ on the PicoGUI homepage:

      Fresco is another GUI (http://fresco.org) that has some similarities to PicoGUI. Fresco has been around for quite a while longer than PicoGUI, but when PicoGUI was started MicahDowty didn't know about Fresco.

      Similarities between PicoGUI and Fresco:

      -Standard widgets on the server side
      -Separation between applications and device coordinates
      -Server keeps a scene graph
      -New GUI architecture, with no backward compatibility
      -Language-independent client/server protocol

      Differences between PicoGUI and Fresco:

      -PicoGUI takes a lot of shortcuts compared to Fresco, to make it more suitable for embedded systems
      -Fresco uses device independent coordinates everywhere, while PicoGUI's themes and layout engine still use pixels
      -Fresco uses CORBA, while PicoGUI has its own network protocol
      -There's nothing like PicoGUI's theme interpreter in Fresco
      -Fresco handles overlapping, and uses a homogeneous scene graph making it more suitable for generic drawing apps and desktop window management
      -PicoGUI has features taylored for embedded systems, such as support for low-end display hardware, and keyboard-only navigation
      -Fresco does real transparency, while PicoGUI usually cheats :)
      -Fresco relies heavily on floating point math, PicoGUI's core is 100% integer. Of course this means that picogui's layout engine has to operate in integer pixel units. (See below)

      Of course they have more in common - both are seen as traitors and main enemy by all the X zealots who come out of their holes every time there's an article about (perhaps) better replacements on /.
    • PicoGUI is somewhat less ambitious than Fresco.

      For instance, fresco has subpixel addressing, a scene graph based windowing model etc. These aren't buzzwords, but I can't really explain them all in depth, i'm too tired right now.

      Fresco is based on corba which is implicitly multilanguage, so that's not just picogui.

      NeWS was an early attempt but it had design issues and never really went anywhere.

      Yeah, I'll second the last comment. It's good to see people trying out new ideas. I suspect that soon X will have most of the features people want in the short term, and we'll all be happy, but that doesn't mean X is perfect and cannot be improved upon. It's good to know people are thinking about a future beyond "we want transparency".

  • I don't see what Berlin/Fresco has to do with the X Window System. Fresco used to be an X11 toolkit, but now it's something completely different.
  • Damn, what a fugly widget set. Hopefully they'll get something better soon.

    How extensible is the API that these people are using, as far as the ability to theme the widgets/windows/etc?
  • A classical fresco is a painting on damp ("fresh") plaster, with the paint penetrating the wall. As such, it tends not to flake off as a painting on dried plaster would, and can last for thousands of years.

    This Fresco is cheap middleware on a product of limited utility, and could last for thousands of days, maybe. Maybe not.

Slashdot Top Deals

"What man has done, man can aspire to do." -- Jerry Pournelle, about space flight

Close