Re: [cross-project-issues-dev] Eierlegende Wollmilchsau

2015-12-09 Thread Michael Scharf 
Hi Doug,

> I could make it the same 16 pixel size but it would look like crap, just like 
> the New Connection…
> item in Michael’s picture (which comes from RSE or TCF, BTW).

To use your words, I think the big controls "look like crap" and the "New 
Connection…"
is just fine.

However, there is a trend to make decisions about the size of fonts and controls
ignoring the system settings. I really really hate that every web page designer
decides which font size I have to use to see their site. It's most of the
time way too big and sometimes way too small. The worst sites are the ones
that do not allow me to change the font size on mobile.

The same is true for eclipse. Follow the font and size settings of the platform.
It's not the job of plig-in "designers" to decide to make buttons extra huge, 
just
because they think their stuff is extra important. ;-)

But the worst part is, I could not figure out how to remove those huge
controls form the toolbar (I was not able to find them in customize perspective)

> For me, the most important thing is the workflow that the launch bar enables
> almost eliminating the need for the user to go to the launch configuration 
> dialog

Hmm for that purpose a eclipse runner

  
https://github.com/scharf/eclipserunnerplugin/blob/master/EclipseRunner/help/Eclipse%20Runner.md

may be better, because switching launch configs is just one click
away and the monster launch bar it may require up to 3 choices before
you can run what you want

Anyway -- the "eierlegende Wollmilchsau" is broken in so many more ways,
like the "run" menu has only one entry: "Run EGF Activity..." and lots
of other broken stuff

Hmm, maybe eclipse needs a app-store like quality control to ensure that
plugins (even the ones hosted on eclipse) do not infer in bad ways with
the UI

Michael

On 2015-12-09 19:16, Doug Schaefer wrote:
> As I mentioned, I turn off almost all the other buttons on every perspective. 
> Only a few editor ones remain that have no equivalent in the menus or 
> keyboard shortcuts. Doing that, it actually looks OK, since there are only 5 
> or 6 of the
> little ones left.
> 
> And besides, I could make it the same 16 pixel size but it would look like 
> crap, just like the New Connection… item in Michael’s picture (which comes 
> from RSE or TCF, BTW).
> 
> The end objective is to present something pleasant to the user’s eye with 
> images that make sense to them. Consistency is a means to an end, it is not 
> the end in itself. Happy users is the end :).
> 
> And, again, if someone can propose something better, I’d love to try it out. 
> For me, the most important thing is the workflow that the launch bar enables 
> almost eliminating the need for the user to go to the launch configuration 
> dialog, and
> to tie what is being built with what, where, and how the user wants to launch 
> it, something especially important to developers working with remote devices 
> and servers. I am less tied to how it looks, as long as it doesn’t look like 
> crap.
> 
> Doug.
> 
> From:  > on behalf of Lars 
> Vogel mailto:lars.vo...@vogella.com>>
> Reply-To: Cross project issues  >
> Date: Wednesday, December 9, 2015 at 12:53 PM
> To: Cross project issues  >
> Subject: Re: [cross-project-issues-dev] Eierlegende Wollmilchsau
> 
> I agree, that the bug lauchbar icons looks displaced.
> 
> Doug, IIRC you usually a argue for consistency in the IDE. IMHO these 
> lauchbar icons should use the same size as all the others, otherwise they are 
> a UI breakage for the user.
> 
> We in Platform plans to bring high resolution support for icons in the 
> Neon release (IIRC Markus Keller works on this.
> 
> Best regards, Lars
> 
> Am 09.12.2015 5:30 nachm. schrieb "Ed Merks"  >:
> 
> Doug,
> 
> Comments below.
> 
> On 09/12/2015 4:58 PM, Doug Schaefer wrote:
>> Thanks Ed! (and Michael for the picture).
> It was kind of entertaining.  In any case, we generate this product 
> along with the rest of the product catalog, so it will always be available 
> for testing.
>> This is awesome and I’m glad we’re finally talking about this. In 
>> fact, I think we also need to go beyond the contents of the simrel repo and 
>> also consider popular 3rd party plug-ins, Pydev and Nodeclipse come to mind. 
>> And Andmore
>> which is coming in Neon will also make this much worse and I’m 
>> planning on helping clean that up.
> Yes, unfortunately once it's installed, it's just all "Eclipse" to 
> the end user, so if others mess things up, they mess it up for all of us...
>>
>> You bring up a great point about the Toolbar. It’s the most obvious 
>> affect of the tragedy of the commons, and it’s why I’m having a personal war 
>> against it. Do these buttons really

Re: [cross-project-issues-dev] Neon M3 is available

2015-11-13 Thread Michael Scharf 
Congratulations!

I wonder if there is a "New and Noteworthy" for M3


Michael

On 2015-11-13 16:29, David M Williams wrote:
> No bad luck today !
> 
> We have "turned on" the Neon M3 repositories for 'update' from previous Neon 
> installations.
> (As a reminder, .../releases/neon is a composite consisting of M3, M2, and 
> M1. Please open a bug if anyone observes any problems with that ... as 
> sometimes happens if features are removed, and similar).
> 
> Plus, many of the EPP packages are available on the developer's download tab, 
> namely
> https://www.eclipse.org/downloads/index-developer.php
> More of them will be available soon, as package maintainers give their "OK" 
> on epp-dev list. (hint, hint :)
> 
> 
> Much thanks to everyone who contributed to this milestone!
> 
> 
> 
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> 

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences

2015-09-14 Thread Michael Scharf 

  
  
Indeed, breaking API without major
  version changes is an absolute
  no go. Even if only a few percent of existing plugins are
  affected, this undermines the idea of APIs and semantic
  versioning.
  
  see also https://wiki.eclipse.org/Evolving_Java-based_APIs
  
   
  
  API Prime Directive: When evolving the Component API from release to release,
do not break existing Clients.
  
      API Contract
Compatibility: API changes must not invalidate
  formerly legal Client code.
      API Usage Assumption: Every
  aspect of the API matters to some Client.
  
      API Binary
Compatibility: Pre-existing Client binaries must
  link and run with new releases of the Component without
recompiling.

  Michael
  
  On 2015-09-14 15:03, Ed Willink wrote:


  
  Hi
  
  This discussion seems to completely ignore:
  
  The major segment number must be increased when a plug-in makes
breaking changes to its API. 

  see
  https://wiki.eclipse.org/Version_Numbering#When_to_change_the_major_segment
  
  Deprecation permits breakage but not violation of versioning.
  
  It is certainly very inconvenient to maintain API forever, but
  arbitrary deletion without a consistent version number change is
  just dishonest; we have distributed code that claims to work and
  it won't.
  
  Perhaps the solution is for the platform to have a major version
  increase every two/three years allowing API clean up. Other
  projects will be more or less forced to synchronize which will be
  a nuisance, but also a benefit, since they too can clean up their
  APIs.
  
  Let Neon be versioned as 5.0.0 and we can all clean up.
  
      Regards
  
          Ed Willink
  


  

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Request for comment: Provide standard update site locations

2013-03-14 Thread Michael Scharf 

Hi all,

I wonder what the sate of "findable" updates sites is? There has not been much 
progress
on the issue recently. I think one problem is to have a common pattern but 
another problem
is "how to find the update site". Today I was looking for the update site of 
EMF 2.9.
This is not easy. Once I found it, it could not update because the plug-ins I 
needed
also needed a new version of xtext. So another round of hunting started.

As a user this is really difficult. P2 solved a lot of dependency problems
but the new type of dependency is to find the correct update site. Once
they are found, p2 does a great job...

Likewise it is also sometimes *very* difficult to find the git/svn repository of
a given plug-in.

Ideally there should be a simple update site and repository search facility
that allows to look up the update sites and the repository for a given
plug-in or feature.

Hmm, thinking of it, it would be nice to get form a package or a class
to the project, the update site, to the repository, mailing list,
newsgroup, and to the correct component in bugzilla etc.

E.g. on the http://projects.eclipse.org page could be a search button
that would find the resources associated with a package, plug-in or
feature.

Or does such a facility already exist and I have not found it?

Michael

On 4/18/12 6:57 PM, Miles Parker wrote:

Hi all,

Please see the bug below. Isn't it about time we had a good common approach to 
this?

377111: Provide standard update site locations 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=377111

Please follow up on bug.

cheers,

Miles
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev




___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev