

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."
AfterStep all the way! (Score:1)
Re:Implementing a "fully transparent" system (Score:1)
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.
Re:Nooo! Not VBA! ME TOO!! (Score:1)
Re:OPEN SOURCE GNOME! (Score:1)
So True. Further, ... (Score:1)
Re:First (Score:1)
Implementing a "fully transparent" system (Score:4)
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.
----
Re:First (Score:1)
Nooo! Not VBA! (Score:2)
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
Re:Implementing a "fully transparent" system (Score:1)
Personally I think Enlightenment already provides more than enough eye candy.
Re:Perl replacing VBA? (Score:1)
Re:Implementing a "fully transparent" system (Score:1)
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.
Re:Apple Aqua NOT JUST Alpha transparency (Score:1)
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?
we want a state address! (Score:1)
"With 'first posts' at an all-time high, our readers are setting world records of obsession with petrification of females"...
Anything in the new FileMan like KFM's browsing?? (Score:1)
AfterStep (Score:1)
oh, wait.. i'm getting mushy.. no... [teary-eyed].. *sniffle*.. help me....
Re:Implementing a "fully transparent" system (Score:1)
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.
Re:First (Score:1)
Time to download 4.7......
Wow! ESR couldn't have said it better. (Score:1)
Why don't GNOME and Redhat get along? (Score:1)
Mmmmm...little green men... (Score:2)
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!
---------------
GNOME, GNU/Linux, and Corporate Desktop Domination (Score:1)
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:
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:
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.
Re:First (Score:3)
It now works for me 100%
Re:First (Score:1)
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.
Evolution (Score:1)
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!
Question:??? (Score:1)
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 ??????
Ok, you found a typo (Score:4)
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!
Re:First (Score:3)
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.
Better and better... (Score:1)
* 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].
Ever tried porting a spreadsheet? (Score:2)
Cheers,
Ben
Re:Implementing a "fully transparent" system (Score:1)
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.
Tog on MacOS X interface (Score:1)
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.
Re:Apple Aqua NOT JUST Alpha transparency (Score:1)
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
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
Re:GNOME, GNU/Linux, and Corporate Desktop Dominat (Score:2)
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.
Re:Why don't GNOME and Redhat get along? (Score:1)
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.
Re:Nooo! Not VBA! (how about..) (Score:1)
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
Re:I can't help but wonder... (Score:5)
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
Re:STATE OF THE TROLLS ADDRESS (Score:1)
I often find (Score:2)
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.
Perl replacing VBA? (Score:2)
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
Apple Aqua NOT JUST Alpha transparency (Score:5)
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.
Re:Implementing a "fully transparent" system (Score:1)
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
Re:Apple Aqua NOT JUST Alpha transparency (Score:1)
No, and by all acounts, it will be soon dropped in favour of Sawmill [sourceforge.net] pretty soon, anyway.
--
- Sean
Re:Ever tried porting a spreadsheet? (Score:1)
Re:First (Score:2)
Daniel
= why to use free software (Score:1)
Re:Implementing a "fully transparent" system (Score:2)
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."
Re:Implementing a "fully transparent" system (Score:1)
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!'
Re:Apple Aqua NOT JUST Alpha transparency (Score:3)
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.
----
Re:Implementing a "fully transparent" system (Score:1)
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.
Re:Implementing a "fully transparent" system (Score:2)
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.
Re:Apple Aqua NOT JUST Alpha transparency (Score:2)
Mark it up as informative. It's perfectly valid.
- Jeff A. Campbell
- VelociNews (http://www.velocinews.com [velocinews.com])
Re:Ok, you found a typo (Score:1)
Re:Implementing a "fully transparent" system (Score:1)
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.
Good Trolls work hard. (Score:1)
Re:First (Score:1)
Re:Apple Aqua NOT JUST Alpha transparency (Score:1)
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?
Where is a linux security faq..? (Score:1)
Thanks
Yes, It's in CVS. (Score:1)
However, to laugh at X is arrogant. Yes, it is ancient, but the protocol was well designed for networks, and it is very extensible.
Re:like X? (Score:1)
Re: libart (Score:1)
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.
Re:Implementing a "fully transparent" system (Score:1)
:: 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 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 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 >
Re:We need Display Ghostscript and GNUStep to comp (Score:1)
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
X Server Code for Rendering (Score:2)
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!
~~
Re:I can't help but wonder... (Score:1)
Re:Ever tried porting a spreadsheet? (Score:2)
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.
Multiple Displays? (Score:1)
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.
Try installing it to it's own dir... (Score:1)
Re:First (Score:1)
Sounds like you need a crash course in how to get of the dang-blasted 'Shop' button [slashdot.org].
Re:Apple Aqua NOT JUST Alpha transparency (Score:5)
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:
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".
Re:Perl replacing VBA? (Score:2)
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...
Re:Yes, It's in CVS. (Score:3)
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
Re:Apple Aqua NOT JUST Alpha transparency (Score:1)
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.
Re:Good Trolls work hard. (Score:1)
Re: libart (Score:2)
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 couldn't find the state (Score:1)
Re:Mmmmm...little green men... (Score:1)
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
---------------
Kool Desktop Environment (Score:2)
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.
GNOME is cool (Score:2)
Conspiracy? (Score:2)
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...
Re:Try installing it to it's own dir... (Score:1)
for all the programs and packages you compile. Not just gnome-libs. Everything needs it. Otherwise the default of
Re:Implementing a "fully transparent" system (Score:2)
----
So said the dinosaur as he sank into the tar pit (Score:1)
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!
Re:First (Score:2)
Re:like X? (Score:1)
Re:I often find (Score:1)
Re:I often find (Score:1)
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.
Correct GNOME User Interface Project URL (Score:3)
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.
Re: libart (Score:1)
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 "DrawPolygonRotateShadeAndAddADropShadowThenDrawT
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...
Re:Implementing a "fully transparent" system (Score:1)
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...
I did that for *EVERY* gnome package... (Score:1)
GNOME's progress (Score:1)
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?"
Re:First (Score:2)
Ahh... Future looks bright. (Score:2)
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?
STATE OF THE TROLLS ADDRESS (Score:1)
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.
Re:Kool Desktop Environment (Score:1)
Re:FWIW (Score:2)
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.
We need Display Ghostscript and GNUStep to compete (Score:3)
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
Re:Apple Aqua NOT JUST Alpha transparency (Score:2)
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.
----
GNOME: Where Does the Funding Come From? (Score:2)
Thank you for your time.