Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
GNOME GUI

Miguel Delivers State of Gnome Address 172

Skeezix writes "Miguel de Icaza has delivered the State of Gnome Address in which he gives an excellent summary of the current state of Gnome, what is being worked on, what the future looks like, and how you can help."
This discussion has been archived. No new comments can be posted.

Miguel Delivers State of Gnome Address

Comments Filter:
  • Yup, I completely agree. Afterstep all the way. That foot looks like it oughtta be in a mouth.
  • Though I have not had an opprotunity to use it,
    just looking at the screenshot shows me a couple
    problems with the Aqua interface.

    * The buttons for min/max/close are not intuitive.
    I'm sorry, but yellow does not immediately say
    "minimize" to me.

    * The buttons are hard to differentiate for those
    of us who are color blind. To make it worse,
    they chose to use red and green, which is makes
    it a problem for the majority of people with
    color-blindness.

    * The close button is next to the rest of the
    buttons. This was one of the few aspects of
    the Mac interface I liked. They broke it.

    * The dynamically resizing toolbar and alpha
    channel transparency. I know some people like
    them, but they are a waste of my CPU cycles.
    If they can be turned on, this isn't much of
    an issue.

    * The apple menu is stuck higeldy pigeldy in the
    middle part of the finder. This makes it a much
    harder target to aim for. Another thing changed
    from traditional Mac OS layout that decreases
    usability.

    I'm sure I could find more if I used the product,
    but that's enough for now.
  • Gnome is DOOMED!! completly dead :((( VBA? oh my god! why not Python or (the FSF way) scheme?? I didn't even know there was vb support for linux... I guess i will have to escape to BeOS ... (is microsoft hand on this?? i mean, spreading vb through opensource would really solve their problem! :) Joao
  • that's truly funny!
  • The point is to cut the weasels (lawyers, robber barrons, wall street types) out of the process of delivering programming. It is a movement to eliminate the Middle Man.
  • IceWM is nice, and probably better as a standalone WM. If you are still using GNOME though, the Sawmill/GNOME combo really rocks. Sawmill's footprint is a bit larger than IceWM, but not massively so, and it has really cool Lisp configurability for look+feel stuff, plus a great theming system, with some very nice themes out there. In terms of configurability, Sawmill has a much slicker config system than IceWM, and the config system is always up to date with the WM. I am not a big fan of the rather ugly IcePref... of course, I can always hack text files, but for some reason I feel like window manager configuration is one of those things that should be GUI-fied.
  • The recent announcement of Apple included some very amazing
    screenshots of what they could do with their technology. I was
    impressed by it for the first two hours, until I realized how easy it
    would be for us to actually pull a hack like that.


    Although the fully-transparent system can be done with little
    effort (as we have a very powerful infrastructure to achieve it: Raph
    Levien's libart) a lot of work has to go *first* into making GNOME
    easier to use, more intuitive and more easy for newcomers.



    If you've seen the screenshot he is refering to [apple.com] that is a pretty impressive statement. Gnome is and is going to be an extremely advanced application framework. But as Miguel points out, there is much work that needs to be done now to make the Gnome Desktop ready to take the world by storm. And no matter who you are, there is something you can do to help.
    ----
  • Tried that, didn't fix the problem. But I did get a "shop" button!
  • Scroll down to the bottom. Apparently under the guise of Excel compatibility this spawn of Microsoft (Bill Gates got started with BASIC, wants everyone to use it) will soon infest Linux!

    Actually, shudder as I might over the thought, it rationally is a pretty good idea. If anyone is interested the authors are Jody Goldberg and Michael Meeks. The mailing list is gb@helixcode.com [mailto].

    Cheers,
    Ben
  • Aqua looks good aesthetically, but I'm not sure if any enhancements were made as to ease of use. The only new thing that I have seen was the pseudo-taskbar thing at the bottom.

    Personally I think Enlightenment already provides more than enough eye candy.

  • I completely agree with you. The strength of linux/gnome and other opensource initiatives have been the freedom of choice. A plugin system with which you could select which srcipting language you want to choose (wether it is perl, java, assembler...) would be great, especially if this would work across several applications. What 's also is important in such a system is that you can choose NOT to use certain language modules that you find a security hazard.
  • > So...you spend alot of time... resizing...???

    No, I was refering to the dock resizing, and for
    that matter recentering itself, when you add an
    icon.

    Using the finder to keep track of running tasks
    is a much lighter approach.

    And if you're going to have a dock, having it
    justified to one side or the other is a much
    lighter approach.

    > Are you easily amused? Hard... to... type from
    > laughing at you...

    Your credibility would be better if you didn't
    respond to an honest criticism with derisive
    comments.

    > Ok UI guru, what icon does?

    Have you ever heard the saying "You don't have to
    be able to lay an egg to smell a bad one."?

    Yellow, as opposed to red or green, typically has
    the connotation of "caution". What does this have
    to do with minimizing?

    For the record, I prefer virtually all other
    options I've seen, including Win3.1, Win95 and
    CDE defaults.

    > Wow, are you one of those guys who also posted
    > everywhere about the iMac not having a floppy
    > drive?

    Wow, are you one of those Mac zealots who defends
    Apple mindlessly as if they couldn't do anything
    wrong?

    Again, for the record, yes, I questioned the logic
    behind releasing a system that neither came with
    removable storage nor had anything availabale for
    it.

    > FYI genius, labels appear when the mouse nears
    > the buttons.

    FYI, I am familiar with the concept of tooltips.
    They are a kludge necessary to overcome badly
    designed, non-intuitive icons.

    There can either be a delay, which means you have
    to wait, read the tooltip, move the mouse so that
    it is no longer obscuring what you were trying to
    click on, and then finally click on the button.

    Or there can be no delay, which is even more
    obnoxious, especially when you've gotten
    accustomed enough to the interface that you don't
    need them, again on the issue of them obscuring
    the screen.

    > Ok, we're all waiting. Get back to us with your
    > report.

    Thank you for your enthusiasm.
  • I agree with you totally. I like gnome and the fact that gtk+ is becoming so prevalent. Let me rehash what i said on gnome-news.



    I've been thinking about something similar to Aqua, ie using some vector-based layer to do all the drawing. I think Apple did a great job.

    I am a total newbie on gnome/gtk internals, but IIRC gtk+ is not tied to X (esp. with the upcoming version), seeing as there are X-less BeOS/win32 ports.

    Would it be possible to write a backend to gtk that writes to postscript (or like mac, pdf). This could sit on a layer that displays pdf to opengl, pdf to ggi (speedier?), or pdf to X. Since you're working with postscript, I guess printing subsystems might be easier too.

    I don't know if it's worth it. It would be easier to create vector based programs, since they could make use of the extra layer. Things like scaling and anti-aliasing would be smoother too. OTOH, you're adding another layer, which means really lowend hardware would have a harder time.

    I have no idea how feasible this is. The ideal would be that all apps except the apps depending on the extra layer would keep working transparantly.



    On another note: since Miguel is aiming for people that never used a computer, it might be interesting to hide files (i know a lot of users won't agree with me on this one, but i think that files you don't use just clutter screen real estate - as long as i can quickly reach them if i really want to it's ok by me) and also to use metadata (again i kinda like macosX's implementation with respect to metadata)

    Could someone enlighten me if there already are similar things being done?
  • Hey, so when do we get a "State of /." address?

    "With 'first posts' at an all-time high, our readers are setting world records of obsession with petrification of females"...
  • Hello, I've read a bit about the HTML widget, will it (or Mozilla, etc.) be integrated into the new file manager to provide anything close to the seemless browsing that one gets in KDE/KFM? Right now, I use KFM for about 25% (light) Netscape for 25% (Heavy stuff) and Mozilla for 50%. Is the HTML widget good enough for general browsing, what about cookies, JavaScript, Java, XML, SGML rendering? So you know, using KFM in Gnome/Sawmill works great. A lot of people still seem to think you can have one of KDE or Gnome. Ben
  • all the way. No hold's barred. Though, I will admit, GNOME looks quite pretty. I think the foot is quite an endearment..

    oh, wait.. i'm getting mushy.. no... [teary-eyed].. *sniffle*.. help me....
  • * The apple menu is stuck higeldy pigeldy in the
    middle part of the finder. This makes it a much
    harder target to aim for. Another thing changed
    from traditional Mac OS layout that decreases
    usability.


    The Apple menu is in the same place it has always been, but now it is the Friendly Mac face menu. That Apple logo in the top middle is just a logo with no functionality. From what I have read, clicking on the mac face in the upper left is the same as clicking on the modern apple menu.

    Also, in regard to your entire comment, the preview of Mac OS X was just that, a preview. OSX is still only in Developer releases, not even beta yet. It will probably change somewhat before the final version.
  • Only problem I have with Gnome is Netscape 4.6.

    Time to download 4.7......

  • Damn funny Suject and succinct statement of what happening. Hope some moderators find this gem.
  • What I'm referring to is the fact that GNOME RPMs install in a seperate directory (/usr I believe) than the default installation via compiling the source (/usr/local). I know you can set that in the configure script, but one time I forgot that and totally hosed my gnome installation. Libraries are now in conflicting directories and Gnome won't start up at all. I removed both directories and started over, to no avail. Anyway, since Gnome is partially funded by Redhat (correct?), why the hell can't they agree on an installation directory?
  • Ideally, we want to make GNOME perfect, easy, small, intuitive,
    resource friendly, portable, maintainable, funnier, entertaining,
    productive, and the ultimate of the ultimates.


    Ahh, if only all Software engineers shared this goal, and without getting paid serious money to boot!

    I think, with this kind of dedication, Gnome could easily be the force bring Linux to the masses. Keep it up!
    ---------------
  • Maybe I'm just stuffy, but I'm concerned that the GNOME community is missing the boat on features that could legitimately make the dream of 'desktop domination' for GNU/Linux a reality. I'd certainly agree that user interface friendliness and a full-featured array of applications are the major factors in getting GNU/Linux onto corporate desktops, and I think competing with Microsoft OS's and Win32 apps on these points isn't the place when GNU/Linux can show the biggest win.

    The 'centralized management' aspects of Microsoft operating systems and most win32 apps are horrendous. Expensive software 'hacks' like Tivoli, LANDesk, Novell ZenWorks, and Microsoft SMS are all ugly kludges to attempt to provide management features for large fleets of PC's. (I just can't say how much these hacks SUCK enough). The fact is, the entire 'single-computer, single-user' metaphor that win32 OS's and apps are based on is completely wrong for centralized management of fleets of PC's. Let's face it-- shit with icing on top is still shit.

    As I look at the state of GNOME now, I'm not seeing the move toward management features that would bring serious money-saving features to the desktops of the corporate world. GNU/Linux being free is not enough for most IS managers to give up their MS-based ways-- the real investment is in management labor (all that 'Total Cost of Ownership' crap). Sure-- today a competent hacker could use scripts and some slight-of-hand to provide many remote management features, but what I'm talking about is providing these features to corporate IS managers in an easy-to-use system. Features like:

    • remote hardware inventory
    • remote application deployment
    • centralized configuration/settings management
    • software metering/use statistics

    The only way I see to provide this correctly is to design it in from the start. Look at the MESS that is win32, and look at the leaps and bounds of hacks SMS, ZenWorks, and all the other 'management' frameworks go through. If we don't get to designing in these types of technologies NOW, we're going to end up with a hodge-podge of configuration repositories, labor-intensive application rollouts, and TCO similar to win32.

    For GNU/Linux to offer serious labor savings to corporate IS managers, I'm talking about things like:

    • An abstracted configuration repository for applications (ODBC style connectivity to a back-end, either decentralized or centralized, much like Microsoft's Registry, but w/o all the brain-damaged stupidity and a GOOD SET OF DOCUMENTED RULES to follow for developers)
    • Standardized friendly application installation methods (which we have today in a large extent w/ RPM or Debian packages-but today's package management systems leave a bit to be desired, IMHO, when it comes to reporting installation error conditions to the user)
    • Some type of hardware inventory initiative that includes interfaces to back-end database systems for report generation (shouldn't really be very difficult-- again, I'm thinking ODBC-style connectivity)

    Maybe we need a Linux Management Initiative or something of that ilk. I'd love to do it, if I was a competent enough coder and had enough time. Instead, though, I'm just a GNU/Linux user stuck working in a win32 based world and dying to get out of it. This stuff isn't glamorous, but I think it's a place that GNU/Linux can kick some serious Microsoft ass.

  • by maan ( 21073 ) on Saturday January 22, 2000 @07:14PM (#1346230)
    If you're referring to the problem of netscape crashing on any page with some java on it...look at http://help.netscape.com/kb/consumer/19990807-8.ht ml
    It now works for me 100%

  • Yes: It is interesting how the Shop button
    Is conveniently located beside the Stop button

    I'm running 4.7 in a freshly installed Frozen Potatoe and I'm not having any problems with it. However, I've only been using it for three hours.

  • I'm really looking forward to 'Evolution', described as : "an integrated client for mail, news, calendaring, tasks and contact management.". I really like gnome-cal (Calendar), but I haven't found a very stable e-mail/news reader. Balsa is very cool, although I've often been having segfaults with the Debian-potato package.

    In other words, new user-friendly applications that are quick and efficient to use, with a cool interface. Rock-on! ;)

    Quick, we need screenshots!

  • One thing that I don't understand:

    Daniel Veillard has finally finished his work to change the > structure of his XML and HTML parsers on gnome-xml, so that > clients can drive the parsing process instead of the clients > driving the parsing process.

    Is it the Clients driving the parsing process or the Clients driving the parsing process ??????

  • by raph ( 3148 ) on Saturday January 22, 2000 @07:31PM (#1346236) Homepage
    2^n++ * 0.01 cents for you.

    This should be "clients can drive the parsing process instead of the parser taking control." This is really cool when you're trying to parse XML and HTML streams from potentially blocking input streams, such as the network. Props to DV for doing this!
  • by Zoltar ( 24850 ) on Saturday January 22, 2000 @07:32PM (#1346237)
    While I have no reason to doubt what you say... I'm gonna stick with KDE for a while. I was totally disgusted with the quality of Gnome/E that shipped with my RH6.0 cd. I love the way it looks but it was not a release product.

    One of the main reasons I choose Linux over everything else was because it WORKS. I don't care how *pretty* it is, it must WORK FIRST, everything else is secondary.

    While KDE looks kinda klunky, it's as STABLE as a rock and I've grown to like it over the past 6 months.

    I don't give a hoot what kind of new technology they are working on if it blows core all over the place and I'm never sure which mouse click will be my last.

    That said...I will give it another try, but only after they release a *stable* version and I see many positive reviews stating that it works.
  • I haven't upgraded some parts of my system since RedHat 6.0, (legacy cruft, don't ask) but I understand that Gnome has come a long way. What I have is already fairly usable, but I'll be happy to see it get better. Here's what I want:

    * a better (more intuitive) filemanager for Unix.

    Even if I don't end up using it, (CLI rules!) I'd love to see at least *one* decent filemanager for Unix, because there are a *lot* of crappy, unfinished ones out there. What KDE has looks pretty neat, at least. (and, once it's completely free, we can borrow / steal it all, ha ha ha!)

    * Interoperability between toolkits / widget sets.

    This is an idea I've had for a while. A consistent theming interface might make my idea obsolete, but in any case, I'd love to have a library that had a front end to handle the different function calls and a back end to map them onto a chosen widget set. Sort of like the GGI project with displays, except for widgets.

    I know how hard this would be to implement, but think about it, 'cause it could save a lot of duplication of effort in the long run. Maybe we could end up working together, and have one awesome set of Unix desktop tools, instead of two pretty good ones.

    * Window manager?

    As far as window managers go, I really like Sawmill. And it looks fast enough and flexible enough to be used for... whatever. Also, now that I'm getting into Lisp and Scheme, it's good to see how useful they can still be...
    ---
    pb Reply or e-mail; don't vaguely moderate [152.7.41.11].
  • If the phrase "spaghetti code" bothers you, your typical spreadsheet is like pulling teeth. Gnumeric may support a million more sane languages, but if they want to ever get anyone to switch from Excel they need to provide Excel compatibility, and that means supporting VBA.

    Cheers,
    Ben
  • I have to disagree.. X is wonderful, X is great, but X doesn't have any sort of advanced graphics system or printing API, which Quartz (and Display Postscript before it) have in spades. There's nothing in X to support arbitrary affine transformations on other X windows/image components, and nothing for doing anti-aliasing, nothing for doing multi-colored fonts, etc., etc. The Gnome folks are doing a super job of implementing those things in Gnome libraries, but doing that means that they've got to pump a *lot* more data over the network to the X server.

    That's why Java 2 is having to do pixel-by-pixel and/or pixmap based imaging operations to do all their fancy stuff. It turns out that if you run a Java 2 application over X on a network, performance sinks to unusability. NeWS may have died, but I would love to see X support plug-in rendering modules so we could implement something like the Java 2 Graphics2d or Quartz renderers on the far side of a network.

  • If you want a lot of good commentary on the MacOS X interface, check out Ask Tog [asktog.com] for his detailed critique of the Aqua interface as demo'ed by Steve.

  • by Anonymous Coward
    I think you should take a second look at libArt, because it does indeed provide the foundation to do this.
    I implemented the Print Preview code and the Print to RGB buffer in GnomePrint in about 2 days of work using libart.
    Yes, this is based strongly on all the code written for libart by Raph Levien.
    The GnomePrint imaging API is inspired by Postscript, so modulo the language, what I did was to implement a Postscript imaging interpreter (which is basically what DPS is).
    Yes, libart can do all of the stuff you described.
    Yes, we could use a higher-level API.
    Yes, you are welcome to implement it
    (that basically implement the Postscript imaging system.
    Implementing a DPS-like API renderer with libart is a few days worth of work. Not much more.
    About fonts, look here: gnome-print/libgnomeprint/{gt1*.c,parseAFM.*)
    Is all of this experimental? Or production code? It depends on what you mean.
    But Gnumeric and Evolution use the GnomePrint with libart for implementing their Print Previews.
    The possibilities of libart are huge, you just need to be creative about it (for example, the GnomePrint Preview code :-) rather than giving up easily.
    Instead of thinking:
    "OH IT DOES NOT HAVE A GRADIENT OPERATION IN THE API! IT MUST BE IMPOSSIBLE TO DO".
    You can think "Mhm, how can I do gradients with this great API? thnk think think OOPSIE! Found a solution".
    I did not bash Apple's work. I just figured "We can do this eye candy; It is not impossible with the current infrastructure we have".
    Again, it requires hacking mind and creative minds; Not flaming minds :-)
    Best wishes, love, etc
    Miguel
  • An abstracted configuration repository for applications (ODBC style connectivity to a back-end, either decentralized or centralized, much like Microsoft's Registry, but w/o all the brain-damaged stupidity and a GOOD SET OF DOCUMENTED RULES to follow for developers)

    The GConf library in GNOME 2.0 is exactly this. I think the hardware inventory and application installation stuff is outside the scope of GNOME though, distribution vendors need to work on those things.

    If you hate the Registry and want this problem solved well, then open source is your friend. GConf is still in flux; you can make sure it's exactly what you're looking for as a sysadmin by reading the docs and sending comments and patches. Right now the latest GConf is in GNOME CVS as module 'gconf', but there will be a release eventually.

  • The GNU standard is that configure defaults to /usr/local. It is broken to install over the top of your RPMs via source compile; normally if you build from source you want to remove the RPMs and install to /usr/local or some other prefix. So the GNU configure defaults actually protected you here.

    The idea is that distribution vendors instal to /usr, and you are supposed to use /usr/local or /opt for third-party or self-installed packages so you don't have conflicts with the RPMs.

    This has been widely accepted as correct for years and years on UNIX, so don't expect it to change.

  • Excel support, although very evil, is a key feature which I think Gnumeric should have. I personally hate VBA, as it is a very evil and unefficient script language, but it would be very good for "transitionnal" users.

    Does the WordPerfect 2000 Linux edition have VBA support? (If I'm not mistaken, the Windows version does).

    Is there currently an application that uses Perl to replace VBA? I'm thinking of some kind of gnome-mod-perl. (If you treat me of heretic, I'll understand ;)
  • *pfffffft*

    That was the sound of water being expelled from my mouth and onto my computer's monitor at a high velocity after reading the above post.

    As someone who uses both Gnome, OpenWindows and CDE regularly (on Intel and Sun workstations), I have to say that, on all accounts, Gnome is by far superior. Much more so when it behaves differently from both OW and CDE than when it behaves like those.

    Sure, there's Lesstif, and there's probably a few dozen Free CDE clones around. But a lot of excellent work has been done on Gnome, to the point where it can be considered far superior for worstation use than CDE. As for porting current apps to Gnome, Lesstif makes it perfectly possible.

    There isn't even the usual excuse of "eliminating duplication of effort". As long as we're writing software on our own, let's try to go beyond what has already done. I mean, look at what happened the last time someone tried to write an Unix clone :)
  • AHAHAHAHAHHA FINALLY a decent worthwhile read from a troll :) right on!
  • cases in GNOME where Win95 did things signifcantly differently -- an example is the configuration box with a series of tabs (Win95's Display Properties, GNOME's Control Center). Both GUIs have the same thing with the same intent, but GNOME's is a bit hard to figure out if you're used to Win95.

    In Win95 the "Apply" button does things that can't be canceled by the "Cancel" button. If you change something, then hit "Apply", then "Cancel", your change takes effect. But in GNOME, each individual panel has its own "Try" and "Ok" buttons. It's much more consistent.

    If you think about how it makes sense to work (how you'd want it to work if you were a new user who had been introduced to the WIMP paradigm but not the historical idiosyncracies of any particular implementation), GNOME is far more intuitive.
  • I am not sure what you mean.

    Certainly may places where VB variants are used, such as ASP, you can also use Perl.

    Additionally with the appropriate modules Perl can drive things through OLE automation using the same APIs that VB uses.

    But if what you want is a way to take a VB script and run it in Perl, I don't think so. Or to embed Perl inside of a VB application? That could also be hard. (ActiveState [activestate.com] sells tools to make dlls and com servers out of Perl, allowing it to be called from within VB. Again I doubt that is what you want.) Sorry...

    Ben
  • by rcromwell2 ( 73488 ) on Saturday January 22, 2000 @07:47PM (#1346256)
    Come on, of course it's trivial to add transparency to the desktop if you have a rendering system that supports Alpha channel. Windows 2000 even supports this, and there are little utilities that let you turn transparent windows on and off. Miguel would be sadly mistaken if he thinks this is all he has to add to GNOME to compete with Apple, or even Java2. Enlightenment/imlib already provides transparency in themes, but they provide *zippo* support to apps that want to render say, a 300DPI illustration.


    What Miguel is missing is that Aqua is not about transparency, it's about Quartz, the Display-PDF rendering system. The NeXT display postscript system and Sun's NeWS could also handle alpha easily, but does anyone think that the only useful feature of Display Postscript or Quartz is being able to render alpha?

    Systems like Quartz, DPS, and Java2D are resolution independent, support anti-aliasing on everything, full affine transformations for everything, virtually all compositing modes you can think of, built in ability to stroke complex shapes, like lines using arbitrary thickness, fill, dash-pattern, and endcaps. For instance, with Java2D it's almost trivial to write a postscript/pdf/svg renderer because the base library is so powerful.

    Miguel's solution might resemble Aqua's transparent windows, but without a real 2D rasterization engine, GNOME apps will never approach the flexibility of Quartz apps in rendering. In fact, he won't even approach the quality of Aqua's nice warping/scaling of images with aliasing artifacts.


    What I really hate is this not-invented-here tendency to automatically superficially evaluate and dismiss other people's technology without even doing 10 minutes of research besides looking at screenshots, and then making public assertions about how trivial it is, and how much better your "solution" will be.

    Clearly, Linux's GUI toolkits need a powerful comprehensive resolution independent 2D API to support powerful display and printing apps. The current mode of separating the display and printing APIs is a pain in the ass to develop for.

    The best innovations are built on the shoulders of others, and if Miguel would spend more time learning and stealing technology from Apple, Microsoft, and even the KDE team, and less time dismissing everything and trying to reinvent it, maybe GNOME wouldn't be so buggy and unusable.

  • ...more than enough eye candy.

    No such thing.

    In addition to a dialog (where I can check/uncheck a hundred or so "eye candies"), we need a slider that incrementally enables groups of features.


    |---------|---------|----------|----------|----- -----|
    xerox park...stark...whatever...sweet...rot-your-teeth
  • > As for Enlightenment, I'm not sure. It's not part of Gnome proper.

    No, and by all acounts, it will be soon dropped in favour of Sawmill [sourceforge.net] pretty soon, anyway.
    --
    - Sean
  • I can say this much, if gnumeric supports VBA and includes the language by default, I stop using gnumeric. I will not have that insecure garbage on my system.

  • ...and the only problem I have with Linux is sendmail...

    Daniel
  • Avoiding management of this type is why I want to use free software.
  • Don't be obtuse -- Aqua isn't about "eye candy", it's about ease-of-use, and that's not something you're going to be able to discern from a simple screenshot. Apple has consistently lead the pack in making their interfaces "inuitive". That word is thrown around, but they've put a lot of effort into making sure they, more than anyone else, know what it means.

    Yeah, Enlightenment more than meets the needs of "eye candy". You can make E look like whatever you want. But it won't duplicate the consistant interface design that Aqua has. Apple has kept a strict set of design guides for this very purpose, so that users will not be confused by their applications. Some people call variety one of Linux's strength... I don't agree. And I'm not talking about customization either. I'm talking about making sure that all of my widgets look the same. That my windows have a consistant look-and-feel.

    -----------

    "You can't shake the Devil's hand and say you're only kidding."

  • Not to say 'I told you so..' but I remember glancing at the OS X screenshots and thinking "Glitzy. Alpha Channeled. Can't be that hard." And Miguel has proven me right.

    It's never hard to copy someone else's design -- nothing to be proud of. Designing the system in the first place so that it looks appealing and works well for the user is the part that's difficult.

    I don't know how well the Mac Aqua interface achieves these goals, but jumping up and down and saying 'Look, we can do this too!' is like copying a painting and saying gleefully 'Look, I can paint this too!'
  • What Miguel is missing is that Aqua is not about transparency, it's about Quartz, the Display-PDF rendering system.
    The NeXT display postscript system and Sun's NeWS could also handle alpha easily, but does anyone think that the
    only useful feature of Display Postscript or Quartz is being able to render alpha?




    Miguel is intelligent enought to know we're not just talking about alpha channeling. He was saying that libart [levien.com] provided the necessary tools. In case you are unaware, libart is a library for high-performance 2D graphics. It is the antialiased rendering engine for the Gnome Canvas. It supports a powerful imaging model which is basically the same as SVG [w3.org] or Java2D [javasoft.com]. It does Vector Paths, Bezier Paths, RGB and RGBA images, Sorted Vector Paths, MicroTile Arrays, and Affine transformations.


    The best innovations are built on the shoulders of others, and if Miguel would spend more time learning and stealing
    technology from Apple, Microsoft, and even the KDE team, and less time dismissing everything and trying to reinvent
    it, maybe GNOME wouldn't be so buggy and unusable.



    This exact approach has been what Miguel has sought after. He is frequently quoted as wanting to take the best ideas from companies like Microsoft, get rid of the bad parts, and integrate them into Gnome. I've personally conversed with him about this exact issue while waiting to watch Phantom Menace on opening night. He says that he doesn't like it when everyone goes around saying Microsoft sucks and that's the end of the story. Microsoft, Apple, and others, have made great strides with their Desktop technologies, and Miguel has been borrowing from them, believe me.
    ----
  • And it is an art form that the Open Source community excels at.

    The Open Source community excels at technical matters, but the open source tradition is a technical one, not an artistic one (yes, programming is an art form to some extent).

    I've no doubt some of the most talented programmers in the world are active contributors to various Open Source projects. But we can't similarly claim that we have the best user interface designers in the world.

    The situation we have now seems to be similar to the situation in the early days of computer games, where programmers doubled up as artists. If we want good user interfaces, we have to recognize that talent in user interface design is separate from talent in programming -- then find the best people in this area and get them to contribute to open source projects.
  • I was impressed by it for the first two hours, until I realized how easy it would be for us to actually pull a hack like that.

    Sounds like some one with a severe case of "Simple Matter of Programming" disease.

    Yes, maybe it would be easy for them to pull off the transparency in menu's etc, but the Quartz foundation of OS X enables transparency, anti-aliasing, seamless import/ export of PDF, and real time manipulation of screen graphics ala the "genie effect" and the realtime resizing w/ aa of the dock elements etc.

    IMHO, his statements about the ease of matching Aqua and Quartz's feature set are pretty heavy in light of, well... have you seen GNOME? It's GTK based over X windows... comparing this imaging model to Quartz is ludicrous.

  • Why was this labeled flamebait?

    Mark it up as informative. It's perfectly valid.

    - Jeff A. Campbell
    - VelociNews (http://www.velocinews.com [velocinews.com])
  • Actually you are VERY right and I thought that not long after making my post. Sure, we can make it look pretty. We could make it look like someone else's prettiness that is.

    But why is it that we can't figure out how to make it pretty for ourselves? Even the Gnome-UI squad only has half the idea.. Looking at their ideas for the next Gnome File Manager, it looks like the "View as Web Page" mode that Win98 has.

    Honestly, can we not think up a whole UI of our own? No more Start Menu's/Feet, no more application Title Bars with a 1-3 button configuration (options, iconify, maximise, close). Do we have to mirror Win9x? Or MacOS? Or can we actually put our heads together and try to dream up some *new* UI concepts? Something intuitive?

    I hope I'm not dreaming.
  • Thanks for that report. A good troll is worth 2 beta testers. Perhaps you could post a troll FAQ. Seems there are a lot of newbie trolls that don't have a clue.

  • Netscape doesn't interact with Gnome. It uses statically-linked Motif instead of gtk+, and doesn't use any of Gnome's features like drag-n-drop. Therefore, I doubt that Gnome is your problem.

  • Umm, what are you babbling about? It is Windows that has GDI, and the NeXT and NeWS systems which use Display Postscript.


    You're on drugs. No other system supports remote display like Windows 2000? Come again?

  • Hey...prob won't read this, but if anyone does, could you point me to an actual Linux security FAQ for an average, relatively new user? I'm having trouble finding one geared towards a home, non-server desktop system
    Thanks

  • Alpha channel support is already in CVS as implemented as a part of GDK-pixbuf. However, to achieve a fully hardware accelerated alpha channel would require a extention to the X protocol, which the Xfree team is very intrested in, and might be eventually based on the current code, if the code is re-released under the X license. There are anti-aliasing widgets for gnome, ala Gnome-Canvas, but it is no where as low level as quartz.

    However, to laugh at X is arrogant. Yes, it is ancient, but the protocol was well designed for networks, and it is very extensible.
  • No, you are wrong. Under X I can easily run an app (a complete application, like Netscape Communicator) one one machine and display its entire GUI on another machine anywhere in the world. I do this all the time when I'm sitting at a Sun but I need to run a Linux app.
  • I still think it has to be in the server. I cannot see any other way to efficiently take advantage of new hardware, or to allow efficient remote rendering. Also huge amounts of data (like true-type fonts) can be cached only in a single place without weird and complex communication protocols, if the server does it.

    There will be a client-side API that hides where the rendering is being done. This is necessary so that the interface can be emulated atop X (like Mesa does). But unless there is some promise that this is going to move to the server, there is very little incentive to try to figure out these libraries.

  • :: Though I have not had an opprotunity to use it, just looking at the screenshot shows me a couple problems with the Aqua interface.

    Not having used it, have you at least viewed the ### Though I have not had an opprotunity to use it, just looking at the screenshot shows me a couple problems with the Aqua interface.

    Not having used it, have you at least viewed the QuickTime demo movies [apple.com] on Apple's site?

    ### * The buttons for min/max/close are not intuitive. I'm sorry, but yellow does not immediately say "minimize" to me.

    When your mouse cursor hovers over any of the three window controls, all the buttons display the appropriate action icons:

    • The red button displays an "X" for close.

    • The yellow button displays a "-" for minimize.
      The green button displays a "+" for maximize.

    Compared to traditional Mac OS Platinum window buttons, this is infinitely better. Whereas traditional Mac OS window buttons were differentiated only by placement and abstract iconic differences, these new widgets are differentiated by color, placement, and easily described icons.

    (Imagine how a tech support guy currently has to explain the old Mac OS grow box to a newbie: "It's the second button from the right at the top of the window, with a smaller square in it. It switches between large and small, or you can option-click it and the window might fill the entire screen." Now it's, "Click the (yellow|second|`minus') button to make the window smaller; click the (green|third|`plus') button to make it bigger.")

    ### * The buttons are hard to differentiate for those of us who are color blind. To make it worse, they chose to use red and green, which is makes it a problem for the majority of people with color-blindness.

    I understand why this would be of concern to someone who is unaware that the button icons are revealed when your cursor hovers over them. But to the non-colorblind world, I assume associating colors to window actions will serve very well both to explain their use, and to differentiate them from the rest of the window.

    Besides, the stoplight metaphor will stick in many people's minds, even if it doesn't do much for me.

    ### * The close button is next to the rest of the buttons. This was one of the few aspects of the Mac interface I liked. They broke it.

    I feel the same, although the Windows model has never been a problem for me either. I preferred Platinum's separation of the close box, but I don't mourn the loss.

    ### * The dynamically resizing toolbar and alpha channel transparency. I know some people like them, but they are a waste of my CPU cycles. If they can be turned on, this isn't much of an issue.

    Hey! This is Mac OS! =P

    ### * The apple menu is stuck higeldy pigeldy in the middle part of the finder. This makes it a much harder target to aim for. Another thing changed from traditional Mac OS layout that decreases usability.

    That's not the Apple menu. That's the Apple logo. =) The Mac OS icon to the far left of the menu bar serves approximatey the equivalent purpose as the traditional Apple menu. (Although I will miss calling it "the Apple menu.")

    ### I'm sure I could find more if I used the product, but that's enough for now.

    Or maybe you'd have better things to say about it. =)

    href="http://www.apple.com/macosx/theater.html">Qu ickTime demo movies on Apple's site?

    :: * The buttons for min/max/close are not intuitive. I'm sorry, but yellow does not immediately say "minimize" to me.

    When your mouse cursor hovers over any of the three window controls, all the buttons display the appropriate action icons:

    • The red button displays an "X" for close.

    • The yellow button displays a "-" for minimize.
      The green button displays a "+" for maximize.

    Compared to traditional Mac OS Platinum window buttons, this is infinitely better. Whereas traditional Mac OS window buttons were differentiated only by placement and abstract iconic differences, these new widgets are differentiated by color, placement, and easily described icons.

    (Imagine how a tech support guy currently has to explain the old Mac OS grow box to a newbie: "It's the second button from the right at the top of the window, with a smaller square in it. It switches between large and small, or you can option-click it and the window might fill the entire screen." Now it's, "Click the (yellow|second|`minus') button to make the window smaller; click the (green|third|`plus') button to make it bigger.")

    :: * The buttons are hard to differentiate for those of us who are color blind. To make it worse, they chose to use red and green, which is makes it a problem for the majority of people with color-blindness.

    I understand why this would be of concern to someone who is unaware that the button icons are revealed when your cursor hovers over them. But to the non-colorblind world, I assume associating colors to window actions will serve very well both to explain their use, and to differentiate them from the rest of the window.

    Besides, the stoplight metaphor will stick in many people's minds, even if it doesn't do much for me.

    :: * The close button is next to the rest of the buttons. This was one of the few aspects of the Mac interface I liked. They broke it.

    I feel the same, although the Windows model has never been a problem for me either. I preferred Platinum's separation of the close box, but I don't mourn the loss.

    :: * The dynamically resizing toolbar and alpha channel transparency. I know some people like them, but they are a waste of my CPU cycles. If they can be turned on, this isn't much of an issue.

    This is Mac OS! >=P~

    :: * The apple menu is stuck higeldy pigeldy in the middle part of the finder. This makes it a much harder target to aim for. Another thing changed from traditional Mac OS layout that decreases usability.

    That's not the Apple menu. That's the Apple logo. =) The Mac OS icon to the far left of the menu bar serves approximatey the equivalent purpose as the traditional Apple menu. (Although I will miss calling it "the Apple menu.")

    :: I'm sure I could find more if I used the product, but that's enough for now.

    Or maybe you'd have better things to say about it. =)

    < tofuhead >

  • Finally, RE: junking X altogether instead of extending the X prototcol... I'm in favor of keeping X and just extending the protocol. We have such a large application base locked up in X that to toss X would be to throw the baby out with the bathwater. X is crufty, and could use a core protocol update, but it's also still good enough for most every day work. We need to either update the protocol (yeah right, like the Open Group is going to bother), or extend it server side.
    The problem with X has parallels with those of the FORTRAN language -- people are producing various requests for- and implementations of- extensions for the language -- but anything that goes into the standard has to be implemented separately by EVERYBODY.

    Extending X has similar problems, since there is no standard way by which an arbitrary X server can be extended.

    To quote the usual quote -- Keep It Simple Stupid -- X already has FAR too much baggage, and adding more isn't going to help it much in the short run (since it takes too long to produce a good implementation), nor in the long run (X's complication gives no real advantages -- network transparency is far better implemented with an extensible window system and network transparent IPC).

    In short, the feature set of a good display architecture needs to be chosen VERY CAREFULLY, not hacked on and extended at will by any old person who comes along. (Consider the question of when X is going to drop its outdated and outmoded font system, or its poorly inadequate pixel based rendering system)
    John

  • No, don't put it in the X-Server. Why?

    Remote display to low-power x-server. Hmmm, those people that use dedicated X-Servers or run their applications remotely (on the Quad Alpha, perhaps!) aren't going to like that.

    Network Bandwidth: 10 mbits/s is still a reasonable amount, and that is the low-end of networks. There is little excuse for not equipping a home network with 100mbit ethernet - if you have multiple computers, you can afford a decent hub!

    A 1024x768 24-bit pixmap is around 3 megs of data - 3-5 seconds to transmit over a low-end network - but Print previews will probably be much less than this in size, and could be implemented in greyscale as an option. On a reasonable network, you could update a 1024x768 image 10 times a second, ignoring latency and network usage...

    So libart et al can send the 96dpi 24-bit colour image to the screen, and a 1200dpi b&w image to the printer (or PS rendering primitives). No need to include the X Server!

    ~~

  • It already exists: it's called LessTif (though without the CDE part) and implements both Motif 1.2 and Motif 2.1 (is that version acually in use?). Check www.lesstif.org.
  • If you don't install GB
    then Gnumeric doesn't support it.
    Simple as that.
    However I don't think the coders are stupid enough to merrily copy all the insecurities of VBA straight into Linux.
  • What's the status on treating multiple monitors as one display?

    Being able to run an editor in one monitor, a debugger on another, and putting your system monitors and email in a third is just plain handy.

  • If you want to see GNOME screw up, try installing it to it's own dir, say /usr/local/gnome. This is not meant to be a flame, it's the honest truth, when. When I installed October gnome to /usr/local/gnome, most of the programs in it *INSISTED* on looking for shared files in /usr/local/share, when they really should have been looking in /usr/local/gnome/share. I think gnome is pretty good, I like the look and feel and stability of KDE much better. KDE 2.0 is coming along very nicely.
  • Tried that, didn't fix the problem. But I did get a "shop" button!

    Sounds like you need a crash course in how to get of the dang-blasted 'Shop' button [slashdot.org].

  • by rcromwell2 ( 73488 ) on Saturday January 22, 2000 @10:25PM (#1346301)
    Miguel is intelligent enought to know we're not just talking about alpha channeling. He was saying that libart provided the necessary tools. In case you are unaware, libart is a library for high-performance 2D graphics. It is the antialiased rendering engine for the Gnome Canvas. It supports a powerful imaging model which is basically the same as SVG or Java2D. It does Vector Paths, Bezier Paths, RGB and RGBA images, Sorted Vector Paths, MicroTile Arrays, and Affine transformations.

    That would be true, if libart really did match the functionality of DPS or Java2D, but unfortunately, a quick look at the API in the header files shows that not only is it insufficient, but it also looks like a very difficult API to use in the first place.

    Consider the following task: Fetch the glyph for the letter 'S', convert it to a bezier path, shear it by 0.3, 0.4. Set this stroke as a clipping path. Next, render the word "Linux rulez", scaled by 2.0/2.0, applying a a gaussian blur kernel to the output (for dropshadow). Next, re render the text with a radial gradient fill overtop of the background. Finally, fetch a penguin icon and render it overtop of the 'I' of the text with 0.3 alpha.
    Of course, all this must be antialiased and rendered pixel perfect. Next, render this in a variety of output formats including:

    1. grayscale
    2. monochrome (1-bit)
    3. ARGB
    4. BGR
    5. palette mapped

    Not only can't libart do this (it has ZERO support for font glyph operations), but libart has no provisions for handling a multiple of pixel formats, nor does it have integrated support for image ops like applying convolutions, and finally, the libart test code to render just a few vpath's is about 5 times longer than the equivalent code required in Objective-C/DPS or Java/Java2D.

    But I'm not bashing libart or Raph Levien. I have respect for his work. I'm sure it will tremendously improve over the next year, when such functionality becomes a "must have", but right now, it's more like an experimental proof-of-concept library in the beginning stages. What I find absurd however, is how the GNOME team keeps putting forward *OBVIOUSLY INCOMPLETE* projects like they are 1.0 FCS versions ready to compete with mature implementations. Like it or not, the current GNOME Canvas can't hold a candle to a Postscript/PDF/Java2D rasterizer, no matter how many times alpha version libraries are asserted.

    My post was marked flamebait, but I view Miguel's comments as the real flamebait. Why does he feel the need to bash Apple's work (I am not a Mac owner and never owned a Mac), like it's so trivial and he's such a master coder that he could just blow Apple and Adobe out of the water if he felt like making the effort?

    Apple's work on imaging in Mac OS X is clearly more than just "skin"/"theme" hacks, and focusing on the cool transparency effects ignores the hard work that went in to actually designing the dockbar user interface. Maybe the GNOME/Enlightenment guys should spend a little more time themselves on UI design, and less on "looks".

  • I think what the person meant was "use Perl instead of VBA as a scripting language for an application." I.e. embed Perl instead of embedding a VBAish language.

    I personally think this is a BAD idea. Don't get me wrong... I like Perl, and I use it a lot. But I use it because I already know the UNIXisms that are buried in Perl. Expecting a newbie who wants to automate a few things in a document or spreadsheet to master the quirks of Perl is asking a bit much.

    A scripting language should be fairly easy for a novice to pick up. At least in theory, VBA is a good candidate for this. The syntax, compared to Perl, C, etc. is much simpler. Less of an overall learning curve.

    The actual implementation of VBA is, however, really lame. The State of the GNOME address pointed out one of the major failings: no security. Hence we get Melissa and other worms. Having worked with VBA, I've come across many bugs and petty limitations that get in the way of what I want to do. The core language isn't that bad, but the interface to applications (such as Word) really sucks in places.

    A previous author in this thread said that GNUmeric should be compatible with VBA. I'm not sure that this is the goal of GNOME's BASIC project... for one thing, you do not want VBA's (non-existent) security architecture anywhere near one of your applications. Another is that you don't want to re-create all of the laces that VBA falls flat. They may get a system that is somewhat compatible (and maybe could use macros in an Excel spreadsheet with some sort of translation mechanism) but trying to recreate VBA enough for macros is just a waste of time, compared to the amount of time you'd put into creating a robust and useful scripting language.

    Perhaps the ideal way to handle this would be to make a plugin system for scripting languages, so you can bang out a macro in whatever language you like. Perl, Python, LISP, Tcl, and this VBA-ish language could all live happily within the GNOME desktop apps. If you know a scripting language already, you can just wade right in. If not, then the VBAish thing should be easy to pick up, and its development tools would be built right into the environment.

    I also wonder how many people actually use scripting languages in applications, such as wordprocessors. I've done a fair amount of it, because I know what macros can do for you. Where I used to work, I found a bunch of cases where people were doing tedious, repetative things that a macro could handle... they just didn't think that there was a better way...
  • by Anonymous Coward on Saturday January 22, 2000 @10:41PM (#1346304)
    > Alpha channel support is already in CVS as implemented as a part of GDK-pixbuf.

    What exactly does this mean? Why aren't my
    widgets translucent? Oh, you mean as part of
    the canvas. Well, that's different. Cool, but
    not quite the same.

    Just because it's in CVS doesn't mean it's done,
    or useful for what we're talking about.

    > However, to achieve a fully hardware
    accelerated alpha channel would require a extention to the X protocol, which the Xfree team is very intrested in,

    Hmm. Some of the developers were asked about
    that very thing, and they said: "that's what
    opengl is for". In other words, they weren't
    keen on the idea.

    And that's only a part of the puzzle. There is
    a whole lot more to Quartz than alpha blending
    (generalized compositing, transformations, raster
    based post-processing effects like the drop
    shadow). Are you going to put all that on the
    server?

    > and might be eventually based on the current code, if the code is re-released under the X license. There are anti-aliasing widgets for gnome, ala Gnome-Canvas, but it is no where as low level as quartz.

    Exactly. Quartz has a single rendering model
    with compositing, affine transformations, etc,
    for the entire system. No canvas/windowing
    system/window manager/widget set boundaries.
    Which is why they can do that, and gnome can't,
    without a significant amount of work at this
    point. And no, a quick hack to make translucent
    menus doesn't count.

    (that's a thinly veiled challenge, gnome folks!)

    >However, to laugh at X is arrogant. Yes, it is ancient, but the protocol was well designed for networks, and it is very extensible.

    Well, they call it their PDF rendering model
    in Macosx, but that's basically an updated
    version of Display Postscript. Which could be
    easily serialized across a network. It might
    be dog slow, but so would X with that kind of
    eye candy, and with DPS you'd have a whole lot
    more room to optimize lowlevel stuff on the
    server side (like compositing), WITHOUT adding server extensions.


    Sorry, X can probably be patched and patched and
    patched to get it to do what people want, and it
    will probably work pretty well, but it won't be
    pretty. Better maybe to start over?


    Peter
  • Hmm, you really want to check out your statement before you write such a bullshit as your statement.

    I can take right now a Linux machine and let any numbers of user (depends ofcourse on the amount of memory I have), and let them login, and each one of them can have its own X session, own Window manager, and each one of them can redirect the display to whatever PC or Unix machine he wants to. For more information - read: man SETENV DISPLAY.

    Contrary to Windows 2000, which maybe lets you redirect the screen (are you implying its doing something like PC Anyware for Windows?), but you have only 1 screen, while on Linux and other unices, the number is virtually unlimited.

  • a troll faq... hmmmmm... that's a really good idea! sounds like a good "collaborative troll" for me and the naked & petrified guy. i wish i'd thought of it!
  • "libart provided the necessary tools."

    I'm going to be very blunt here. This stuff should be IN THE X SERVER!!!.

    I don't want to link with a giant imaging library for all my programs, I don't want to send image maps to X for all my drawing, and I really want my advanced imaging model to be able to take advantage of advanced hardware!

    If the code exists, lets put somewhere where a mortal programmer can actually figure out how to use it, and better programmers may have a slight chance of improving it! It is absolutely disgusting that we have a worse graphics interface that NT, or than NeWS (which was created in 1983!). And it is quite alarming that people are saying that gigantic shared libraries running in my program's memory space will save us. It is theroetically possible to draw everything using a library that calls XDrawPoint(), that does not mean it is a good idea!

    PS: although there is a lot of push for it because "thats how MicroSoft did it", there is no need for X to do printing. What is needed is the ability to send *IDENTICAL* streams to two different things and get an image on the screen and on the printer. The screen thing can be a wrapper driver around the lower-level X interface.

  • I betcha it's California...
  • Of course, the one time I don't preview...oh well!

    Ideally, we want to make GNOME perfect, easy, small, intuitive,
    resource friendly, portable, maintainable, funnier, entertaining,
    productive, and the ultimate of the ultimates.


    The emphasis there should've been on perfect :)
    ---------------
  • Personally, as a former Windows 95b user, I prefer KDE [kde.org] over GNOME. However, I use tons of the GNOME apps that came with my RedHat 6.1 distro. I simply find the KDE interface more intuitive (or probably just closer to what I'm used to) and more stable. It's good to read things like:

    The wm-spec team is almost ready with their new window manager specification which is unified across GNOME and KDE.

    Anyways, I wish the GNOME team the best. If you're not a programmer, you can still help by sending in bug reports as you find the need to do so.

  • I've been using October GNOME and sawmill for quite some time now. Anyone saying that its less stable than kde now is just plain wrong. I decided to give kde a try. I tried to force myself to use it. I gave up after a few days. Gnome's desktop is trully customizable. No two gnome-desktops after being customized to ones needs are alike. Gnome's panel has the best applets. If you like mini apps these kick ass. From a cpu monitor network monitor icq mini-commander pager deskguide. many diffrent clocks. Drawers are great too they let you consolidate your shortcuts. Oh well thats enough for now.
  • "*Bug fixing GNOME.

    If you are interested in doing some detective work, and helping other people. This is also a great way of learning about the various GNOME framework libraries: it will expose you to real problems in real applications (boy, I sound like Microsoft hiring material)."

    Conspiracy? Of course not... That would be just a little too logical... ;)





  • ./configure --prefix=/usr/local/gnome
    for all the programs and packages you compile. Not just gnome-libs. Everything needs it. Otherwise the default of /usr/local will be used.
  • I have to disagree. It is possible to begin with another's idea and work to "copy" it, but then enhance it. Would you categorize Linux as just a copy of Unix? I look at it this way: You see a good idea and think to yourself, "How could I implement this? Could I improve on it?" And as you implement it, new ideas come to you. It is very much an art form. And it is an art form that the Open Source community excels at.
    ----
  • Quoth the mammal: "What is dead is the notion of selling software as if it were a physical widget. Instead, we are moving to a world where programmers code to solve problems, and then share that code amongst each other to increase the size of problem-solving space.

    Employers will pay coders to solve those problems because solving those problems help their business. This is, in fact, the employment model used by the vast majority of programmers, it is those who try and sell code who are the minority.

    Those who are the slaves are those who work long hours for little pay and empty stock options hoping that their labours can be sold as product. This model can never hold, as the greatly larger free software community will always beat them on quality and price.

    Coding software is a SERVICE industry, not a manufacturing industry. We are more akin to mechanics than to farmers. We are highly skilled operators of machinery that fix problems. We produce nothing!

    Those who do not learn this lesson are doomed to fail.

    You may not want to work on GNOME, but thousands of others do. They will eat your lunch.

    THIS is the Open Source revolution!
  • I absolutely understand your feeling about Gnome/E as shipped on RH6.0. It's a disaster. However, the latest stable gnome (1.0.53 which is 1.0.54 on my system somehow) is a far different critter, much more stable. I generally despise Enlightenment for it's obtrusiveness and grandiosity which has gone from bad to worse, so I replace E with IceWM 1.0.1 This is much nicer feeling than E, IMO, cause it does what you want a windowmanager to do and doesn't constantly call attention to itself. IceWM 1.0.1 and October gnome has made Gnome liveable for me, finally, although in the months since RH6.0 I have spent a lot of time in KDE, and more lately discovering lighter environments and windowmanager combinations. Now that I can stand gnome, I'm not sure I want or need a "desk environment". I rarely use the start menu thingy for either Gnome or KDE and the other panel apps aren't too compelling in either case, so I'm kind of pared down to IceWM+DFM (a good file manager that's attractive, unlike Gnu Midnight Commander, which I could never stand the sight of). Lighter combinations are faster and IceWM's Gnome compatibility and the fact that DFM itself is gtk based allow me to use "Gnome" gtk apps transparently with the file manager without having to run a Gnome-session desktop. It has also solved 95% of my angst about KDE's clunky look and heavy footprint. This at last is about all i want or could ask from a Linux desktop and I'd recommend it to anyone who's underwhelmed by overblown desktop environments and not afraid of doing a samll amount of text configuration.
  • You will have to provide a better description than that. Running a program on a remote box with it's display on a local machine is exactly what X does.
  • Gnome its self is all around a much better system than kde. First of all it offers technical benefits way beyond kde. Gnome offers an object linking architecture, where as kde does not. As an enterprise application developer, this is a verry important thing. The ability to encorporate different portions of other applications into a new application by simply linking to an object in your application and controling it through an exposed interface, without having to specific build both applications to implement a custom rpc based message passing architecure is very important. Most contemporary businesses have indivudalised computation needs in order to run their buisness, and need to intergrate these needs with thier pre-existing, off the shelf application enviornment. Being able to do this by accessing autmation interfaces to these applications from custom applications make these intergrations seemless to the user. This is a powerful feature. If linux is ever to replace win32 in a desktop enviorment (capturing the buisness market will ultimetly lead to capturing the home market), a viable alternative to m$'s com arcitecture needs to emerge. Gnome, imho, will eventualy get to this point. KDE, however, isn't even striving to do this. I use gnome now, because its better now, and it will be ultimetly better in the future.
  • I'm sorry to say this, but as much as I like GNOME, I think you've used the single worst example of "consistency" and "usability" in GNOME as it currently stands.

    Although there are huge benefits in having evey configuration item accessible from the one window (ala GNOME and Netscape, as opposed to Windows & Mac Control Panels), I think it's massively counter intuitive to provide "try", "ok", "cancel" buttons for each separate entity and *especially* when you have to colourise the ones that haven't been confirmed... I really recommend a look at the new Mozilla config panel - very slick, thanks to the work of Ben Goodger.
  • by adraken ( 8869 ) on Saturday January 22, 2000 @09:12PM (#1346329)
    Miguel mentioned the GNOME User Interface Improvement Project:
    Currently GNOME lacks a bit of polishing when it comes to the end desktop because we do not ship a good set of presets for it. Shipping good presets and revamping the user interface (as suggested by our user interface team at http://www.gnome.org/gnome-ui) is a really important task.

    The real URL is at http://developer.gnome.org/gnome-ui [gnome.org].

    The great thing about developing interfaces with GNOME is the libglade architecture. Designing an usable interface is easier if you can rapidly design it in such a program and if you can tweak and revise it at runtime.


  • Well, a better solution than just blindly adding more stuff to the server is to raise the abstraction level at the client end. Instead of making lots of calls to lots of APIs that invoke lots of special features of the server, make the client interface higher level, and do a better job of hiding the distinction between client and server. A good example is NeWS. You write snippets of postscript, and whatever is rendering it can do it's best to make it go as fast as it can. Or OpenGL with display lists. You're right about lots of calls to SetPixel being the wrong thing, but then do we end up with "DrawPolygonRotateShadeAndAddADropShadowThenDrawTh eButtonOnTop"?

    I don't know TOO much about what I'm talking about, but making a clumsy distinction of the server then randomly adding features (which is really how it would be with X) seems like the wrong thing.

    Plus with client side APIs, you don't really CARE where it's actually being rendered. If you have something nice and declarative (like a canvas type thing) the lib makes use of whatever it has, X server or what have you.

    repeating myself trying to make my point...
  • So how does Aqua improve on the original Mac interface? By making windows slither across the screen at the cost of several MFLOPS? I have seen a number of examples of Aqua 'at work' and the main difference is they re-arranged the buttons on windows and special effects.

    I just thinks it's silly to upgrade the old Mac interface only to add pretty colours. The concept behind display PDF is pretty cool though...



  • And guess what, most programs still *INSISTED* upon looking in /usr/local/share for files when they *SHOULD* have been looking in /usr/local/gnome/share
  • GNOME's progress is looking good. I still prefer KDE over GNOME for many reasons, but there is no reason to start a jihad over Window managers.

    GNOME looks nice, and is getting (thankfully) more stable than it was when I first tried it out. While it may be hard to give up my beloved KDE, I'll definately give GNOME another chance when I feel it is on par with KDE for my needs. ^_^

    "You ever have that feeling where you're not sure if you're dreaming or awake?"

  • I have found kde to be less intuative and less stable than October GNOME. GNOME may have gotten itself a reputation of being unstable because of its release early release often strategy but the stable release of GNOME is in fact very stable. KDE however doesn't make releases very often. So people only get exposed to their stable stuff. While distributors like Redhat put GNOME on their cd while its in prerelease. (e.g Redhat put pre-October GNOME on their 6.1 cd) This prerealese is unstable. I have seen it freeze up. For anyone who thinks that GNOME is unstable download the latest October stuff and think again.
  • That was one informative message, I must say. From GNOME user's point of view it's nice to see the GNOME folks are doing such hard work and thus the project is advancing rapidly.

    So GNOME 1.2 is coming (not that soon, though). And Linux 2.4, Debian GNU/Linux 2.2, FreeBSD 4.0, XFree 4.0, Mozilla and GCC 3.0 are on their way and probably they all are released before Q3/2000.

    It's so great to be a Free Unix-like system user, don't you agree?
  • dear friends,

    many people (cute teenaged girls/hot young actresses/men and feminazis) have asked the troll team, where are the trolls headed in the future? when is a new troll coming out? what are the new features that are going to be included in the new trolls? what can we expect from them?

    * the troll state.

    there are many areas into which the troll project is expanding; you have to keep in mind that trolling is an umbrella project which is made up of various components:

    * the OPEN SOURCE trolls: these are trolls that may or may not start out being semi-ontopic but usually quickly decay into something wholely irrelevant. there is, at times, an "open source" theme. natalie portman and/or drew barrymore often appear in these.

    * the NAKED & PETRIFIED trolls: these trolls usually focus on the petrification of cute teenaged girls, hot young actresses, men and feminazis. these trolls usually involve the turning to stone of these groups. natalie portman often appear in these.

    * the GRITS trolls: these trolls exclusively deal with the various aspects of grits-pouring. these trolls will almost always include the grits being poured down one's pants.

    * the X trolls: i won't mention them by name, because they are proprietary. going too deeply into the issue would ruin it for you. they know who they are.

    * the MEEPT trolls: none of the above.

    the various trolls of the slashdot trolling project have their own release schedule, which lets the troll authors compose their works as the inspiration hits. from time to time two trolls organize a collaborative troll. the most recent collaborative troll was "OPEN SOURCE COLLABORATION."

    * the short future of the trolls.

    we have been doing a lot of work infrastructure-wise and sometimes we have failed to be very communicative about it. it is our fault, and we need to do a better of job at telling people what we have been up to.

    ideally, we want to make our trolls perfect, easy, small (or long), intuitive, resource friendly, portable, maintainable, funnier, entertaining, productive, and the ultimate of the ultimates.

    we will ideally try to get the following features in the next major release of our trolls:

    * less on-topicness

    * more inflammatory

    * more gender neutrality (we are sensitive to the concerns of the feminazi movement here on slashdot)

    * multi-size panel, smoother icons, more panel types, nicer art work.


    * the long term future of the trolls
    ultimately our goals are to open source hot young actresses, men, cute teenage girls and feminazis as well as to turn them into stone.

    we also wish to eventually drain all moderation points out of the system.

    * how you can help.

    * moderate the shit out of us!
    * respond extensively to our trolls!
    * become a troll yourself!
    * send us money!
    * send us pictures of hot young actresses, cute teenage girls, men and feminazis!


    thank you.
  • To a certain extent I think that's what GNOME's heading for (the more-intuitive interface). Well not specifically at the window manager level, but by proposing to replace the huge, bloated, ugly Gnome Midnight Commander with something else...
  • "And regarding Java 2d: I don't think that's
    a solution. Doesn't it have the same problems
    with the division between UI and graphical
    canvas? Can you embed a button in a drawing
    and rotate...drop shadow, all the while having
    it update automatically?"

    Java2D and Swing were developed in parallel, if I remeber correctly. Also swing components are 'light weight' which means that they were created using java2D.

    In fact JComponent has a method which returns a Graphics object. This allows you to draw on the JComponent using the jav2D API. So, while I haven't done much graphics programming in Java, I think it's possible to do what you suggest.


  • by Xlib ( 106134 ) on Sunday January 23, 2000 @03:03AM (#1346351)
    Consider the following task: Fetch the glyph for the letter 'S', convert it to a bezier path, shear it by 0.3, 0.4. Set this stroke as a clipping path. Next, render the word "Linux rulez", scaled by 2.0/2.0, applying a a gaussian blur kernel to the output (for dropshadow). Next, re render the text with a radial gradient fill overtop of the background. Finally, fetch a penguin icon and render it overtop of the 'I' of the text with 0.3 alpha. Of course, all this must be antialiased and rendered pixel perfect. Next, render this in a variety of output formats including:
    1. grayscale
    2. monochrome (1-bit)
    3. ARGB
    4. BGR
    5. palette mapped
    This is a very insightful post. And you're right, libart goes nowhere near this in functionality. Nor can the client-side anti-aliasing support in GNOME be really said to compete with NeXT's and Adobe's old display postscript, nor with their new Display PDF.

    As others have pointed out, this stuff must be in the X server (display server) since to be effective it should be hardware accelerated. The only project which comes near this is GNUStep with Aladdin's Display Ghostscript project. If I remember correctly, the DGS will be an X server extension for the client side widget libraries, so for those X servers with DGS support GNUStep will have hardware accelerated Display Ghostscript -- just what you seem to require.

    Of course, the GNUStep project has taken a long time to mature... but they seem to be nearing completion of their core libaries and DGS code, leaving application support left. Since their libraries are close enough to MacOS X and the old OpenStep specification it should be fairly easy to port between the two.

    I like GNOME a bunch, but honestly I loved my old NeXT CUBE a whole bunch more. I'll happily buy a PowerMac G4 if MacOS X turns out as nicely as my old CUBE did...

    Finally, RE: junking X altogether instead of extending the X prototcol... I'm in favor of keeping X and just extending the protocol. We have such a large application base locked up in X that to toss X would be to throw the baby out with the bathwater. X is crufty, and could use a core protocol update, but it's also still good enough for most every day work. We need to either update the protocol (yeah right, like the Open Group is going to bother), or extend it server side.

    I'm under the impression that the XFree86 team is having some legal (patent) issues about including TrueType support directly in the newer XFree 4 X server, which is why they're going to only support TrueType font servers. If this is true, then that's another good argument for pursuing a Display Ghostscript model and dumping TrueType support altogether.

    Cheers,
    Xlib
  • Yes, the reason your post was marked flamebait was due to comments you made then and now bashing Miguel and the Gnome Project. I really think you underestimate Miguel's understanding. He wasn't just making a flippant remark about some "skin/theme" hack as you put it.

    What I find absurd however, is how the GNOME team keeps putting forward *OBVIOUSLY INCOMPLETE* projects like they are 1.0 FCS versions ready to compete with mature implementations.

    I think you misunderstood the spirit of the post Miguel made. Some of the newer Gnome technologies such as Bonobo and the Gnome Print Library were not being put forward as ready for prime time. The entire point was to say we're still working on them, they need some more hacking before we'll release them in a public manner.

    Maybe the GNOME/Enlightenment guys should spend a little more time themselves on UI design, and less on "looks".

    Work is being done to that effect with the Gnome User Interface Improvement Project [jcinteractive.com]. Some of the ideas they've come up with have already been implemented, others are still being hacked on. As for Enlightenment, I'm not sure. It's not part of Gnome proper.
    ----

  • by Anonymous Coward
    Friends, those of you who watch the wonderful Fox News Channel know that Bill O'Reilly has been doing an excellent series on the Linux operating system and the GNOME desktop environment. He's been doing some digging and has come up with some preliminary results that he's going to unveil on "The O'Reilly Factor." Well, I got an advance copy of his results from the web site, and so I thought I would share them with you and the rest of the community. It is important that we monitor these people and make sure we know what they're up to.

    • The ACLU (Anti-Christian Litigation Unit) donated $10,000 directly to Miguel. There can be no doubt that this money is a reward for the development of software that is intended to promote communism. The ACLU will not stop until we are all ruled under their iron fist. It makes sense that they would donate money to a cause that has the destruction of capitalism and decent Christian society at the top of its list.

    • The American Atheists also made a sizable donation to the FSF, with the express condition that the money go to the GNOME project. The check was signed by Madalyn Murray O'Hair herself .. before she was killed by some noble soul .. so this means that the atheists, as an organization, must have been prepared for this! They must have known years ago that somebody would invent some sort of technology that would work to attack capitalism at its roots, and they wanted to have the check signed in advance. If there was ever any doubt that atheists are pathetic socialists, that doubt can be dispelled.

    • The Sierra Club donated $25K to the FSF as well, and while they did not specify that any of that money was to go to GNOME specifically, you can bet that the free software commies and environazis made some sort of slick deal behind the scene. Environmentalism translates directly to communism, and it should come as no surprise that these tree-hugging hippies are in bed with the GNOME socialists. What will their slogan be next year? "Plant a tree, erase a Windows partition, destroy capitalism?" Friends, that's probably not too much off the mark.

    • Troop 317 of the Girl Scouts of America donated 50% of the proceeds from their cookie sales to the FSF. Friends, while it is heartwarming to see young women being prepared for the role of cookie-preparer (as is demanded by Scripture), it is sickening to see girls band together in a cheap imitation of the Boy Scouts. This smacks of feminism, and is probably the work of the damnable National Organization for Women. Patricia Ireland and the rest of NOW are most likely behind this socialist donation.
    So there's the money trail, friends. We will have to watch this closely. But to any and all GNOME-friendly people reading this post, know this: We are on to you. Do you understand me? We're on to you. You'll have to be a little more careful in the future, my socialist compadres. We're one step ahead of you all.

    Thank you for your time.

BLISS is ignorance.

Working...