Mac Look and Feel improvements
Locked
12
12
 
|
While attempting to utilise Andrew Blakeley (much!) better Mac look and
feel I found I could not get it to work on 7.8 and later. Besides it loads a lot of extra classes which I feel should not be part of a look-and-feel package. Before trying to create some improvements myself, I feel I should check here: I cannot believe others have not put some effort into this, because the standard Mac OS X Aqua look and feel is just so horrible. Anyone? _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
rob.vcf (554 bytes)
Re: Mac Look and Feel improvements
|
|
On Feb 17, 2012, at 12:21 AM, Rob Vens wrote: While attempting to utilise Andrew Blakeley (much!) better Mac look and I don't know if the dev builds are an option for you Rob, if they are, you might try them with skins turned on. It doesn't fix the whole look and feel by a long shot, but it begins to put a dent in it. Especially the push buttons on 10.7. Next weeks build, the pinstripes should be gone hopefully (regardless of skins for that part). I'm working on scrollbars currently. They're tricky to see the least. I've got them kind of working, but have some edge cases to smooth over. -- Travis Griggs Objologist "I think that we should be men first, and subjects afterward." - Henry David Thoreau _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Mac Look and Feel improvements
|
|
In reply to this post by Rob Vens-2
Rob Vens wrote 17 Feb 2012 10:21
> While attempting to utilise Andrew Blakeley (much!) better Mac look and > feel... That sounds interesting - I hadn't heard of a new Mac L&F policy, and can't find it with the search terms that come to mind, in either the public repository or Google. Any chance of a name / link / screenshot? Cheers, Steve _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
if I'm not wrong this is ASBAqua look and feel for Mac OS X, from Antony Blake
It's a nice work Antony did but, if I remember well, He dropped because lack of interest and support from community/cincom.
This open up a lot of questions.
Look and feel is really not up to date on VW, and Travis work is great and a really good improvement, but when it will be finished? And "when" is the problem.
In the meantime customers did work, and we have Win 7 L&F, and we had this Antony work, and the big work done by Andre.(private one).
Question is: why Cincom has been unable to catch this work and move it on the supported distribution, and in the meantime working for the fabulous definitive answer that we are happy to get, but we have trouble (well supported by the history) about when (and if) it will happens sometime?
Any case, Travis, thanks for what you do, just, don't stop...
ciao
Giorgio
On Fri, Feb 17, 2012 at 9:44 AM, Steven Kelly <[hidden email]> wrote: Rob Vens wrote 17 Feb 2012 10:21 _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Mac Look and Feel improvements
|
|
imho it would already help a lot, if there would be a proper ObjectiveC connect (much like Michael Lucas Smith's ObjectiveC-2.0 Runtime), where you can also create Subclasses of Cocoa classes. With that working you could create your own native interface in Interface Builder (or most recently in Xcode itself) and then load the nib file and have your objects used in there. Then you'd have 100% native look and feel, at the cost of rewriting your frontend for Mac OS X though.
I think it'd be easier to improve Objective-C than create an up to date look and feel. But that's just my 2ct. Karsten Karsten Kusche - Dipl. Inf. - [hidden email] Georg Heeg eK - Köthen Handelsregister: Amtsgericht Dortmund A 12812 Am Freitag, 17. Februar 2012 um 12:01 schrieb giorgio ferraris:
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
this is only one side of the solution...
I personally don't wanna learn Xcode, and I like cross platform portability, so that is non a viable solution for me, and I think for many others. But surely is a solution.
ciao Giorgio On Fri, Feb 17, 2012 at 12:15 PM, Karsten Kusche <[hidden email]> wrote:
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Mac Look and Feel improvements
|
|
In reply to this post by giorgiof
Thanks Giorgio – and stupid me for forgetting that the VW search field only searches for matches at the start of the string, so my ‘Mac’ ‘OS X’ etc. searches all failed. Steve From: giorgio ferraris [mailto:[hidden email]] if I'm not wrong this isASBAqualookandfeelforMacOS X, from Antony Blake It's a nice work Antony did but, if I remember well, He dropped because lack of interest and support from community/cincom. This open up a lot of questions. Look and feel is really not up to date on VW, and Travis work is great and a really good improvement, but when it will be finished? And "when" is the problem. In the meantime customers did work, and we have Win 7 L&F, and we had this Antony work, and the big work done by Andre.(private one). Question is: why Cincom has been unable to catch this work and move it on the supported distribution, and in the meantime working for the fabulous definitive answer that we are happy to get, but we have trouble (well supported by the history) about when (and if) it will happens sometime? Any case, Travis, thanks for what you do, just, don't stop... ciao Giorgio On Fri, Feb 17, 2012 at 9:44 AM, Steven Kelly <[hidden email]> wrote: Rob Vens wrote 17 Feb 2012 10:21 > While attempting to utilise Andrew Blakeley (much!) better Mac look and > feel... _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Karsten Kusche
Am 17.02.2012 um 12:15 schrieb Karsten Kusche:
> imho it would already help a lot, if there would be a proper ObjectiveC connect (much like Michael Lucas Smith's ObjectiveC-2.0 Runtime), where you can also create Subclasses of Cocoa classes. With that working you could create your own native interface in Interface Builder (or most recently in Xcode itself) and then load the nib file and have your objects used in there. Then you'd have 100% native look and feel, at the cost of rewriting your frontend for Mac OS X though. > > I think it'd be easier to improve Objective-C than create an up to date look and feel. But that's just my 2ct. That won't work, because the OE (hence all Smalltalk code) is running on a secondary native thread. All UI code is required to be called on the native main thread (the event loop), or the application will misbehave and crash sooner or later. Calling out to AppKit from the Smalltalk thread is a bad idea. There may be workarounds that lock the event loop in some way, but those will have a stark impact on performance. In order to make this work, I had to add a layer of Objective-C code to the VM that takes care of thread synchronization. Andre _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Mac Look and Feel improvements
|
|
In reply to this post by giorgiof
On Feb 17, 2012, at 3:01 AM, giorgio ferraris wrote: Question is: why Cincom has been unable to catch this work and move it on the supported distribution, and in the meantime working for the fabulous definitive answer that we are happy to get, but we have trouble (well supported by the history) about when (and if) it will happens sometime? This is a great question. I once felt very strongly and similarly bewildered by this. It was in the hey day of the Linux distro business, and I wondered why Cincom didn't spend more time just integrating/maintaining stuff, leaving the development to the actual community. I remember writing a similar rant to the above, but I was longer winded (nothing new there) and more aggressive about it. I think there was even a pilot project I was writing that I wanted to nominate as an example of how that could work. I remember amongst the replies a guarded comment from Eliot Miranda that was something like "OK, but you'll have to be patient with us, our standard for code quality is pretty high." At the time, I didn't get this. I remember thinking "you're kidding me right??? Some of the code in the Cincom base is anything other than what I'd call high quality. I'm pretty sure our group does a better job than Cincom does currently when it comes to code quality and getting things done." I bit my tongue (rare for me). Now I work at Cincom, have for a bit. I understand this better. I don't think Eliot's statement was quite clear (I wasn't listening well enough?), but I think I get the essence of it better now. There is lots of good stuff out there, good add ons, etc. Our community writes good stuff. But they have the luxury of making assumptions. They also have the luxury of just walking away if they're not interested any more. What's really high for us, is the attempt we have to make at *thoroughness*. A lot of the assumptions that people make, based on their world view of how to do work or how to write applications or what end users expect, simply don't hold up. What turns out to be high, is our need for thoroughness. Take ExtraEmphasis as an example. It does OK at what it does. But when I wrote it, I didn't need to care about CompositeFonts (used for Japanese and other Asian installations). So I didn't. To integrate it, I need to sit down and do a bit of thorough research figuring out well it plays with CompositeFont instances, looking for edge cases, testing, etc. It also makes assumptions about how one gets character widths that are ok, but not really correct long term. Again, more research and work and testing. Alan Knight calls this the 90-90-90 rule. The first 90% is the easiest. It's the second 90% that gets you. And what really bites, is the third 90% that hits after you've planned for the second 90%. Customers send fixes for various GUI glitches all the time. They'll say "we've been using this for a while, and don't see any problems." I am very grateful for these, I'd rather have them than just whining (hint, hint). But the work is usually far from done at that point. They don't have to worry about Windows Remote Desktop, or 8bbp X11, or some weird OSX-ism. Or writing tests. Or formatting the code. Or trying to be consistent with the rest of the library. I can't tell you how much unbelievable minutia and tedium I do as VW engineer that I never truly anticipated, and that's sad, because I don't think my peers consider me one of the "shining examples of thoroughness." The other aspect is that "Luxury of Walking Away". At any time, I can sit down (with my copious free time) and write ExtraEmphasisToo, fixing everything I think was wrong with the first one, using first class objects for emphases, etc. Even if I don't do that, EE is an extra. If someone doesn't like it, they can change it, or fix it, or improve it, or whatever. They can make whatever assumptions they want about its presence in their system. And if I quit maintaining it, no biggie for me. The point is, Cincom isn't really responsible for EE at the moment, or any of the permutations and expectations that may go with it. The minute we integrate that… that all changes. What has impressed me, is the true variety of ways people will come to depend on Cincom production code. We don't seem to have the Apple-esque ability to say "there is a right way to use our stuff, you're not doing it right, and the right way is our way." Beck and company built this whole methodology around the idea of keeping the cost of change low and constant. It works great for an end product. You can completely rewrite the search engine under an application, you own the user interface and can fix it accordingly. We don't have that luxury at all. So anything we tend to pull in, has this long term calcifying effect on our code base. I'd say the biggest challenge Cincom has facing its code base, is that it includes 20+ years of questionable design decisions (along side a lot of good ones), that we're stuck living with now. Short term solutions end up being a loan against long term design debt, and we've been borrowing from the bank for a long time now. But because people come to depend on the nature of those loans, we can't just declare bankruptcy and move on. Long winded. Probably no better than Eliot's original response. Maybe I should've just said "I so empathize with what you're wishing for. I've said the same before. I really wish it could be. But I've come understand why it's more complicated than that. And I wish I could figure out how to articulate it clearly."
--
Travis Griggs Objologist "Some of them wanted to sell me snake oil and I'm not necessarily going to dismiss all of these, as I have never found a rusty snake." --Terry Pratchett _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Rob Vens-2
Hi Rob and everyone,
by incident, I have just finished a new Mac/Windows L&F a couple days ago. I would much love to share the code with everyone, but unfortunately it still has dependencies on other custom packages and my time is extremely limited currently. It's also not yet tested on the latest release of VW. The reason I posted this is that I wanted to show how a strict and simple visual concept can be helpful, even without using Cairo et al. I uploaded a few shots in a haste, so please bear with my rather random selection, but I am sure you get the idea: http://www.sonity.com/scratch/index.html Andre _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Mac Look and Feel improvements
|
|
In reply to this post by Travis Griggs-4
On Fri, Feb 17, 2012 at 11:57 AM, Travis Griggs <[hidden email]> wrote:
Far better. Well put. I remember seeing a documentary on the sorry state of US political and cultural life a few years ago in which a native american criticised main-stream US culture as being obsessed with rights but unwilling to accept responsibilities. It has stayed with me. Cincom is responsible for VisualWorks. We can demand the right to submit code to VisualWorks all we want but it would be irresponsible of Cincom to integrate any code into the base it couldn't look after properly. And of course one can't shirk responsibility for any bad code in the base either.
That would have shirked your self-imposed responsibility to explain yourself fully to the community. Please keep doing so. I for one really appreciate your patient elucidations.
best, Eliot _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Mac Look and Feel improvements
|
|
In reply to this post by giorgiof
On 17/02/2012, at 9:31 PM, giorgio ferraris wrote: > He dropped because lack of interest and support from community/cincom. I understand Travis's points completely. The unfortunate upshot is that outside contributions are always in a parlous state, and given the conservatism of Cincom's customer base, are unlikely to be taken up in any significant way. VW isn't an open source product, and IMO contributors should accept upfront that they're really only amusing themselves working in VW. To contribute you need to work for Cincom, and alas, I don't. The current skin approach is IMO a good idea. If you want to contribute, do it in Pharo/Squeak. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Some defeats are instalments to victory. -- Jacob Riis _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Hi Antony,
On Sat, Feb 18, 2012 at 6:37 AM, Antony Blakey <[hidden email]> wrote:
That's not *quite* what I heard. Conservatism isn't the issue, but the need to be both innovative AND thorough if one's expecting them to take on your contribution in a way they become legally obligated to support. This is common sense, not ideology, and I didn't sense from Travis that they're terribly happy about having to be so, uh, principled (read: difficult). VW isn't an open source product, and IMO contributors should accept upfront that they're really only amusing themselves working in VW. To contribute you need to work for Cincom, and alas, I don't. Or join their developer program, in which case you get all their products, including those in beta and early release, and are able to experience a feedback loop that gives you a more realistic taste of the rigors of their in-house development process. But, to be clear, they have that program specifically for people who wish to contribute potentially to the code base, to have their ideas affect CinCom's direction more directly. So if you're *really* serious about contributing to VW, and have the time, that is an alternative. The current skin approach is IMO a good idea. Pharo is a great Smalltalk that's getting better and also has a lot of rigor in the development process, I perceive from its very active lists. However, I have found that things I need of a more enterprise variety have to be cobbled together, as it were, manually. Quick example: Making HTTPS XML RPC calls to third-party APIs. Even after installing XmlRpcClient equivalents in VW and Pharo, I was more stymied by Pharo than VW in terms of getting up and running. In VW, someone in the non-commercial community very quickly (like, within minutes of my posting my problem) pointed me to the process for installing a bundled cert so that I no longer got a RootNotTrusted error (from their built-in X.509 security library). However, it did not work out of the box in Pharo, whose security libraries are not built in or as easy to get working with the open source HTTP client libraries. Oh, I know, it's free and open source and I can drink more beer, or implement my own solution to the free HttpClient library, or proxy my calls through a local Apache server on my linux machine, or whatever, but actually, I have a project on tight deadlines and VW posed the fewest serious obstacles to a cross platform solution with the fewest moving parts. I'm sure there is a good answer for Pharo to this problem, and I'm also sure it's just a matter of piecing together libraries that probably weren't designed to work together, and aren't supported and may or may not have been thoroughly tested. Indeed, I often find myself excited by this or that open source project, only to learn whole considerations, like security, are left as an exercise for the reader, or to be implemented in a future, unspecified release, or assume a support infrastructure of system admins and the like that I don't have. Incidentally, Dolphin, which is windows only and uses the HTTPS capabilities of the MSXML API -- a proprietary beast if ever there was one -- worked 100% out of the box without any problems or fiddling with certs, and I only had to make one change to the free XMLRPC library that someone ported from VW to get it to work. I just can't use it on my Linux server. But it was technically the one that I had making calls to these services with the fewest manual steps on my part -- albeit we're talking about changing one line of code in Dolphin instead of running, say, 5 lines of code in VW. So, life continues to be trade off. I expect Pharo to one day be an enterprise-class environment with all the necessarily whiz-bangs built in, it's going firmly in that direction, and I don't think that day is far off, but I also don't think that day is today. So by all means, contribute to every Smalltalk you use! One day I hope to have time to do so myself. ;) Bless you, - Bob
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Mac Look and Feel improvements
|
In reply to this post by andre
Andre,
You have without any doubt one of the best looking interfaces around here. But why is it that you decided not to use Cairo ?
Regards,
@+Maarten,
Author Said: "andre" <[hidden email]> | > Hi Rob and everyone, > > by incident, I have just finished a new Mac/Windows L&F a couple days ago. I would > much love to share the code with everyone, but unfortunately it still has > dependencies on other custom packages and my time is extremely limited currently. > It's also not yet tested on the latest release of VW. > > The reason I posted this is that I wanted to show how a strict and simple visual > concept can be helpful, even without using Cairo et al. I uploaded a few shots in > a haste, so please bear with my rather random selection, but I am sure you get the > idea: > > http://www.sonity.com/scratch/index.html > > Andre > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Mac Look and Feel improvements
|
|
In reply to this post by Bob Calco
On 18/02/2012, at 8:28 PM, Bob Calco wrote: > Or join their developer program, in which case you get all their products, including those in beta and early release, and are able to experience a feedback loop that gives you a more realistic taste of the rigors of their in-house development process. But, to be clear, they have that program specifically for people who wish to contribute potentially to the code base, to have their ideas affect CinCom's direction more directly. All my work was under the dev programme, and I didn't get that sense. > So if you're *really* serious about contributing to VW, and have the time, that is an alternative. I was full time on contributing to VW, but in any case I'm not making a point about my particular contribution, just that the process that Cincom is required to adopt given their business conditions, isn't conducive to third party contribution, and there's no real market for third party add-ons/mods. IMO this has as much to do with the essence of Smalltalk as anything else. It doesn't modularise well, and monkey-patching is only the tip of the iceberg, IMO of course :) I loved working in VW, and improving the interface in particular was a lot of fun, but then I *was* amusing myself. Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 I contend that we are both atheists. I just believe in one fewer god than you do. When you understand why you dismiss all the other possible gods, you will understand why I dismiss yours. --Stephen F Roberts _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Maarten Mostert
Hi Maarten, Cairo has never been an option for me. I don't like the idea of having two separate graphics layers mixed. At least when I last tried, this caused many "off by one pixel" issues and crashes. I suspect there is also a high potential for nesting errors and deadlocks due to the mixed use of two APIs that both lock the graphics medium. The other concern was footprint size and deployment. My way was to rewrite the existing VM primitives to use native Quarz and leverage GC locking to the maximum possible extent (roughly that's double buffering done by the window server). I added native thread synchronization to the VM that ensures AppKit compliant graphics calls. The solution is light weight, flicker-free, fast and backwards compatible with the existing VW base. The downside is it took me years to get here, while it actually should have been ready to use from the beginning. That's why I do not refrain from occasionally showing that "it can be done", in the hope Cincom will pick up at least a bit of it. Andre _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Travis Griggs-4
Hi, Travis,
thanks for the answer. I can understand. ciao Giorgio
On Fri, Feb 17, 2012 at 8:57 PM, Travis Griggs <[hidden email]> wrote:
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Contributing changes to Cincom Engineering (Was: Mac Look and Feel improvements)
|
|
In reply to this post by Antony Blakey-2
On Feb 18, 2012, at 4:37 AM, Antony Blakey wrote:
> > On 18/02/2012, at 8:28 PM, Bob Calco wrote: > >> Or join their developer program, in which case you get all their products, including those in beta and early release, and are able to experience a feedback loop that gives you a more realistic taste of the rigors of their in-house development process. But, to be clear, they have that program specifically for people who wish to contribute potentially to the code base, to have their ideas affect CinCom's direction more directly. > > All my work was under the dev programme, and I didn't get that sense. I think this is a good segue into something that I often think needs to be enumerated a bit clearer. I am going off of the original question which was something like "Why is Cincom so slow to integrate things that are in the public community?" Antony expresses some understood frustration. This is directed at those who write software that why wish Cincom would be more proactive about integrating into the product. The first thing to understand is that there is a difference between an extra and an integrated product. The whole point of "integrated" is that it gives up a large amount of its individual identity in the interest of becoming part of the greater whole. When you have a piece of software you wish would get integrated, I think this is the first thing you have to emotionally/philosophically come to grips with. Am I writing this as an add on? Do I want to maintain general control/direction over what it is, and how it evolves. If you decide you like it distinct, then you get to stop there. Sadly, you can't have your cake and eat it too. If it's yours, you get to do whatever floats your boat, no need to worry about any of this. But if you do find yourself hoping your efforts diffuse into the base product, there's things you can do to make it more likely/easy. Do you have to do these? No. But the more you do, the higher the odds, because the resistance to getting it integrated. All of those ideas pull abstractly from XP/common sense principles, and from experience having sat both sides of the fence, as well as having contributed to various open source projects outside of Smalltalk. Format your Code Seriously. We use the standard formatter with standard options for all of the GUI/Tools code. External code that is to be integrated, just means I have to go format it all. But it runs a little deeper than that. We try to use things like real variable names, intention revealing selectors, method arguments that are of the anArtileAndMabyeAType format, while locals use specificRoleNames, standard conventional variables such as 'each' for loop arguments (or eachSomething). Every deviance from this kind of stuff, means more work for a Cincom engineer to bring the code to be integrated into some sort of harmony with the rest. We have all too many historical examples of where this hasn't happened. Everyone of those has been taking out a long term loan that we have to pay for. Many people have their own little styles and add on things they like to do. It may be of value to you, but from an integration pov, it's just a barrier to having it integrated. Write Tests Good unit tests help. Good unit tests are rarely good validation tests, you can try to use a framework like SUnit(Too) to do both, but the kind that mean more to me personally are the kind that emphasize design over validation. Comment your Code This goes along with the format stuff I guess. There's a standard style, template, etc. If you don't fill out, if you don't comment the important API methods and how they're to be used, it's just work I have to do myself. Use proper sentences in method comments. We don't want your specialized/personal method of annotating variable names of whatever. Match the Metaphor Where it makes sense, match the general metaphors of the rest of the system. Too many times I have been encouraged to integrate something that drags a bunch of other metaphors along with it. Metaphors that might work for the contributing individual, but add baggage to what the essence is. Talk to an Engineer It pays to talk to someone ahead of time, and during the development. You may think we really really really need a new XML parser and would like to write one, and want us to integrate your newer and better one when you're done. We may point out that we're too obligated to ours. Or that features you want to have, we tried already, and while they're good, there's another concern (such as performance) that governed what we did. For example, if you're the "The more tunable options the better" type of guy and you insist on writing your goodies with the hope that Cincom will gobble up, then it's unfortunate that you didn't talk to me first and get a good drumming about the ears about less is more and design/interaction simplicity. Keep it Small and Focused Monster pieces of functionality are tough to allocate a sufficient slice of time to deal with. Smalltalk pieces of software can fit in between the cracks better. "I rewrote all of the browsers, please integrate them" is harder them smaller/simpler things. But even more important, so often these various packages that we should just gobble up, come with little extra baggage. A couple of additions to the base that the developer thinks are handy. An addition to the launchers menus. An inspector tweak. Etc. Leaving those "extras" out greases the skids better. Manager/Helper/Worker Objects Beware If I see this kind of smell, it's an immediate turn off for integration. It means I will probably have to do a lot of work to redesign the object oriented aspect of your contribution. This and other design smells can be far more difficult for us to overcome than the above issues. The "Talk to an Engineer" can help a lot here. -- Travis Griggs Objologist Light travels faster than sound. This is why some people appear bright until you hear them speak... _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Mac Look and Feel improvements
|
|
In reply to this post by Travis Griggs-4
Well, for some reason I missed trying that approach. It seems
promising to me, the simplicity of the current implementation seems
nice too.
Turning on skins creates a few glitches (for example in the settings window buttons are not enabled/disabled properly or do not fire click events properly) so am I right it is not yet completely integrated into the system? On 17-02-12 09:37, Travis Griggs wrote:
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Mac Look and Feel improvements
|
|
In reply to this post by Bob Calco
Bob Calco wrote:
> Or join their developer program, in which case you get all their > products, including those in beta and early release, and are able to > experience a feedback loop that gives you a more realistic taste of > the rigors of their in-house development process. But, to be clear, > they have that program specifically for people who wish to contribute > potentially to the code base, to have their ideas affect CinCom's > direction more directly. So if you're *really* serious about > contributing to VW, and have the time, that is an alternative. That isn't the only purpose of the vw-dev program, though it's one of them. That program provides early access to our development builds immediately as they are built. That can be useful for people who are maintaining or creating additional components. It's also useful for customers who want to know what's coming and be able to comment on it before it's finalized. From our point of view perhaps the most important thing is that it gives us the opportunity to have problems reported early. With a product that's used in a huge variety of different ways and in which people can customize any part of the image or even the VM, it's very difficult to test against all possibilities, so early feedback from real users is extremely helpful. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |